Hi all,

Within Enterprise systems it is quite handy to have reflection such as done in .NET and Java. Of course, D is more down to the system, but it could prove handy when using things like SOAP or CORBA. Since in D a class (and methods/templates etc.) are not capable of reflection immediatly (and this has a strong reason) I still think that there should be support for it, so one could easily make a SOAP, CORBA or other connection to and from D.

For this it may be nice to introduce a new keyword (actually an attribute) to be put in front of a class, method and perhaps template signature:

# reflect class ClassThatReflects {...}
# reflect ... someMethod(...) {...}
# reflect template SomeTemplate(...) {...}

--- or ---

# class ClassThatReflects {...}
# ... someMethod(...) {...}
# template SomeTemplate(...) {...}
# // ... further down ...
# reflect ClassThatReflects;
# reflect someMethod;
# reflect SomeTemplate;

Enterprise systems in these days exist because of those techniques, but also XML invokers (which search methods/classes belonging to some element) could benefit from such a system.

Regards,
Sjoerd

Sjoerd van Leent wrote:
> Hi all,
> 
> Within Enterprise systems it is quite handy to have reflection such as done in .NET and Java. Of course, D is more down to the system, but it could prove handy when using things like SOAP or CORBA. Since in D a class (and methods/templates etc.) are not capable of reflection immediatly (and this has a strong reason) I still think that there should be support for it, so one could easily make a SOAP, CORBA or other connection to and from D.
> 
> Enterprise systems in these days exist because of those techniques, but also XML invokers (which search methods/classes belonging to some element) could benefit from such a system.

Maybe this needs to appear on a FAQ someplace. :)  (if it doesn't already, that is)

There has never been any dispute that reflection is a good thing to have.  It's just not on the Right Now List. (as I understand it, the Right Now List is currently composed entirely of unfixed bugs)

With respect to the potential overhead inflicted by having this extra information exposed at runtime, it only needs to appear once per class, not instance, so it's pretty small in the long run.

I think the right thing to do would be to have a pragma to explicitly suppress this extra reflection information.  This way, it's more clear that it's a mere optimization, as opposed to an important concept of the language. (smarter compilers could ignore it in much the same way that most C++ compilers regard the 'inline' keyword as a mere hint)

 -- andy