Edward Diener wrote:
Andrei Alexandrescu wrote:
Edward Diener wrote:
I argued for this in the past on this NG but still no one seems to
have picked up the idea that a full reflection library for D,
supported fully by the compiler, would be a great thing. It would
also allow RAD programming with D outside of the functionality one
could use in 3rd party tools designed around full run-time reflection
capabilities.
D2 will have reflection. (Walter doesn't know yet. He thinks D3 will
have reflection.) It will be compile-time reflection because only
run-time reflection only is missing the point.
The whole debate about "compile-time" and "run-time" reflection is
irrelevant as long as one can invoke it without having to inject code
into an already existing construct.
It must work through run-time code which can ask such reflection
questions as: enumerate for me all of the classes in a particular module
etc., or enumerate for me all the functions in a class etc. . It must
work by allowing code from outside of a construct to query that
construct and get its accessible constructs. How that run-time code is
written, whether using "compile-time" reflection using templates, or
run-time classes accessible from a library whose reflection data is
produced by the D compiler, is not important from the user's point of
view as long as the user has the access he wants and can write
relatively clean and clear code to get it.
Of course from within any given construct one should also be able to
write code in a clear manner which accesses the inner constructs.
Access to constructs via reflection should follow the same protection
features as any other code, so that public constructs are always
accessible but private constructs are only accessible following their
normal rules.
So I do not know what you mean by "only run-time reflection only is
missing the point" but certainly the ability to use reflection at
run-time is vitally important from outside of a construct to any 3rd
party tool which wants to introspect already existing constructs and
create objects from those constructs based on the information run-time
reflection can return.
This is a long discussion, but in brief any runtime reflection engine
needs some sort of compile-time metadata infrastructure. Some languages
don't make that accessible within the language itself. Runtime
reflection has been explored extensively, its possibilities and
limitations are pretty well understood, I hardly smothered a yawn
reading all you wrote. Compile-time reflection is much less understood
and hides many more exciting possibilities. With the advances in
compiler technology implemented by Walter, we have a chance to tackle
reflection in a systematic manner.
Andrei
