www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - namespace (for export)

reply spir <denis.spir gmail.com> writes:
Hello,


In a previous post, I asked how to define, in a module, a set of symbols fo=
r 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 qu=
estion is why, because for me a field is just a special var, and a method j=
ust 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 w=
ith "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 l=
anguage'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 exp=
ort, neither). I cannot test them, for instance. They must be globally decl=
ared, forcing to repete ids in 2 separate locations in code, leading to bug=
s 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 s=
tupid in thinking this, but why should the compiler be able to evaluate a m=
odule's top-level symbols at compile-time? What we want is them to be avail=
able at _import_ time. In my view, the compiler's task here to build a repr=
esentation of the code (ie to compile, not to evaluate), e basta. Like a fu=
nc def, which will is run when called only. For a module's toplevel, call-t=
ime 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 h=
ere -- about staticity, certainly. Please help me understand ;-), if it is =
the case.


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 25 2010
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
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
Nov 25 2010
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
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...
Nov 25 2010