namespace (for export)

[Jonathan M Davis]

On Thursday 25 November 2010 02:09:27 spir 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.
> 
> 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.

All variables must either be within the global scope, a class, a struct, or a 
function (including unittest blocks and static constructors which are actually 
functions, albeit special ones).

All statements must be within a function.

I really don't get what you're trying to do, since previous posts on this topic 
that you've made indicate that you're trying to put statements at the module 
level, which makes no sense at all. All statements must be in a function and 
thus have an execution path. The module itself is for declarations only. It has 
no execution path, so it never run statements, and so it makes no sense to put 
them there. All a module constructor is for is initializing global variables at 
runtime. It's completely different from trying to put statements directly in the 
module.

If you want to take code in one module and paste it into another, you probably 
either want string mixins or template mixins: 
http://www.digitalmars.com/d/2.0/template-mixin.html

Hopefully that's of some help. But you seem to be trying to do something so 
alien that I'm really having trouble understanding it is that you're trying to 
do.

- Jonathan M Davis