On Tuesday, 27 November 2012 at 21:48:52 UTC, Walter Bright wrote:
On 11/28/2012 3:59 AM, David Nadlinger wrote:
On Tuesday, 27 November 2012 at 15:49:45 UTC, Gor Gyolchanyan
wrote:
Can you implement this use case?
Have classes mix in something,, which will register them in a
single
place,
which can later suppl the registered classes as a type tuple.
This is fundamentally impossible in the D module system if the
"single
place" S does not import the modules where the types are
defined. Even
if you could append strings to a "compile-time global" in S,
this still
wouldn't help you in any way because if you tried to mix in
the string
in S, you'd get nothing but a slew of undefined symbol errors.
Maybe you can describe your use case a bit? I'm optimistic
that there is
a solution which is not radically incompatible with the design
of D.
David
In general, D even tries to avoid the concept of a "global".
Modules are supposed to be unknown (and unknowable) unless they
are imported (directly or transitively).
However, modules can self-register their contents to some
imported "registry" via code in their static constructor.
I do not think this is a burden, because UDAs cannot be
externally applied to an import. A module must be editted and
the UDAs specifically added to them, so adding some boilerplate
to the static constructor should not be an issue.
And for several years we've been trying to tell you that that
does not work in the presence of circular imports.
