namespace (for export)

[Simen kjaeraas]

spir <denis.spir at 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