Hello,


In a previous post, I asked how to define, in a module, a set of symbols for export.

I was blocked then mainly because the compiler did not let me freely define what I wanted to define, at the module's toplevel. Especially, it does not allow accessing (public) fields or methods of defined elements. A first question is why, because for me a field is just a special var, and a method just a special func. The language seems to let call any other kind of func, or access any other kind of var (I have not stepped on other limitations).

All those blockages magically disappear when put inside a 'static this () {} block'. This firstly shows that the language is fully capable of coping with "free" definitions; and to make them available for export. So, why not allow them at the module's toplevel? I cannot see any difference from the language's point of view.

An annoying consequence is that what's defined inside 'static this' is not available in the module itself (EDIT: they seem not to be available for export, neither). I cannot test them, for instance. They must be globally declared, forcing to repete ids in 2 separate locations in code, leading to bugs after any edit (frustrating ones, like in those languages where interface must repeat implementation).

Finally, I guess from "static" in "static this" that the issue's key point has something to do with evaluation at compile-time. Maybe I'm completely stupid in thinking this, but why should the compiler be able to evaluate a module's top-level symbols at compile-time? What we want is them to be available at _import_ time. In my view, the compiler's task here to build a representation of the code (ie to compile, not to evaluate), e basta. Like a func def, which will is run when called only. For a module's toplevel, call-time is import-time. (For an app's single or main module, call-time is just run.)

These reflexions probably show you how I'm missing some fondamental point here -- about staticity, certainly. Please help me understand ;-), if it is the case.


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

spir <denis.spir@gmail.com> wrote:

> Hello,
>
>
> In a previous post, I asked how to define, in a module, a set of symbols for export.
>
> I was blocked then mainly because the compiler did not let me freely define what I wanted to define, at the module's toplevel. Especially, it does not allow accessing (public) fields or methods of defined elements. A first question is why, because for me a field is just a special var, and a method just a special func. The language seems to let call any other kind of func, or access any other kind of var (I have not stepped on other limitations).
>
> All those blockages magically disappear when put inside a 'static this () {} block'. This firstly shows that the language is fully capable of coping with "free" definitions; and to make them available for export. So, why not allow them at the module's toplevel? I cannot see any difference from the language's point of view.

Would you mind giving an example of what you mean here? I have a bit of a
hard time envisioning your code.


> An annoying consequence is that what's defined inside 'static this' is not available in the module itself (EDIT: they seem not to be available for export, neither). I cannot test them, for instance. They must be globally declared, forcing to repete ids in 2 separate locations in code, leading to bugs after any edit (frustrating ones, like in those languages where interface must repeat implementation).

This is related to my point below. static this is (mostly) an ordinary
function, and obeys scoping rules as such.


> Finally, I guess from "static" in "static this" that the issue's key point has something to do with evaluation at compile-time. Maybe I'm completely stupid in thinking this, but why should the compiler be able to evaluate a module's top-level symbols at compile-time? What we want is them to be available at _import_ time. In my view, the compiler's task here to build a representation of the code (ie to compile, not to evaluate), e basta. Like a func def, which will is run when called only. For a module's toplevel, call-time is import-time. (For an app's single or main module, call-time is just run.)
>
> These reflexions probably show you how I'm missing some fondamental point here -- about staticity, certainly. Please help me understand ;-), if it is the case.

static is a highly overloaded keyword. In the case of static this, it does
not mean compile time. Instead, static this is a module constructor, run
at run time, before the program enters main.

-- 
Simen

I might be off track, but I think I know what you're getting at.

You want to define a set of module scope variable that are initialized when the program starts up:

eg. A struct that stores information loaded from a configuration file (can't be done at compile time)

--------

module foo;

struct ConfigData
{
 ...
}
ConfigData myData = loadFromFile();

--------

This then doesn't work because loadFromFile can't be called at compile time, and therefore can't be used to initialize a global.

You've then done:

--------

module foo;

struct ConfigData
{
 ...
}

static this()
{
  ConfigData myData = loadFromFile();
}
--------

Which works, and runs on program startup, but doesn't let you access
anything defined inside the static this from another module.
If I'm right so far, then the solution is to seperate the definition and the
initialization:

--------

module foo;

struct ConfigData
{
 ...
}

ConfigData myData;

static this()
{
  myData = loadFromFile();
}
--------


In order to get the best of both worlds...