On Sunday, 7 December 2014 at 06:25:48 UTC, ketmar via
Digitalmars-d wrote:
On Sun, 07 Dec 2014 05:42:31 +0000
bitwise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
what you actually want is some cross-module compile-time data
storage.
this is impossible to implement. at least to make it reliable.
with separate compilation, for example, you can't get list of
"all
modules", 'cause we can link other unimported modules to the
final
executable. this is somethimes useful with "extern", for
example.
and there is no such thing as "main module" too, so there is no
"root"
for symbols.
besides, some templates can be not instantiated at the time you
doing
compile-time reflection, for example. that is why my console-ng
requires that "register all" mixin must be the last line in the
module.
with some efforts and hackery you can walk all imported
modules, but
this can fail at unexpected places.
tl;dr: things aren't that easy when it comes to compile-time
reflection. either live that to runtime or write compile-time
wrappers
and restrict compile-time reflection usage to well-defined
places and
patterns.
I think I understand what you mean. I've been surprised with the
way D is able to handle circular references, but I guess there
still has to be some order of initialization at the end of the
day.
Thinking about my current design, I believe there are places
where circular references could cause problems, but that I have
yet to find them because I haven't properly tested against a
large/complicated codebase.
I think the best plan for me would be to store all reflection
information in the reflection module itself as local static
variables of templates, i.e. Meyers singleton style. This would
disallow me from reflecting private members, but would greatly
simplify my design. Also, the mixin could then be used
exclusively for registering runtime reflection, and be placed
anywhere.
I would like to be able to reflect private members though... Is
there any way to give a module private access to an unrelated
module?
I'm thinking of something like placing a pragma at the top of a
module or adding a qualifier to a module declaration.
#pragma privileged
or
module reflection privileged;
I understand that packages are meant to solve this problem for
regular code, but given the fact that D has such a comprehensive
reflection system, it would be nice to have this special case.
