namespace (for export)

[spir]

On Thu, 25 Nov 2010 03:03:24 -0800
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> 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.

In the general case, defining symbols requires kinds of statement (but I don't see what you mean by "statement" as for me an assignemnt is the archetype of a statement, so how can you define anything?). Anyway, if I put definitions in a func, as you propose, then how can I have the symbols available for export? The answer seems to be: declare them first as globals. Right, but then we get this double definition issue (not that serious, just annoying); it's just a useless hack.
What I don't understand is why the language refuses the same exact definition at the toplevel that it accepts in a func.
You seems to take it for granted that I cannot write:
	auto myExportedSymbol = new T();
	...
	myExportedSymbol.i = 1;
but for me there is no obvious reason why D refuses that, and accepts
	T myExportedSymbol;
	static this () {
	   auto myExportedSymbol = new T();
	   ...
	   myExportedSymbol.i = 1;
	}
It's the same thing, from my point of view: when I import the module, I get the symbol correctly defined. I don't get why a module needs a constructor: why else has it a top-level?

> All a module constructor is for is initializing global variables at 
> runtime.

Precising runtime to import time, that's exactly what I'm looking for. How can one do it without static this?

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

spir.wikidot.com