Andrei Alexandrescu wrote:
BCS wrote:
Hello Andrei,
Nick Sabalausky wrote:
Stdout.formatln("{}", __FUNCTION__);
I think instead of __FUNCTION__ we'll define a much more comprehensive
static reflection facility.
for the above case I think __FUNCTION__ is as good as it will get.
Define it as a human readable identifier rather than reflection.
You will have it as a human readable identifier too. The problem with
__FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what
happened to __STRUCT__, __MODULE__ et al?) can go forever.
These macros are the wrong idea. As you say the bare macros can go on
forever. What is really needed in a reflection library is the ability to
'reflect' all D constructs, and you would get much more than just the
name in such a library.
So pushing for __FUNCTION__, __CLASS__ etc. etc. is just a quick-fix
solution whereas a real reflection library gives so much more.
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.
