On 2011-08-21 14:55, Marco Leise wrote:
Am 21.08.2011, 14:11 Uhr, schrieb Jacob Carlborg <d...@me.com>:
BTW, you're already paying for the class info.
That could be a necessity of D's OOP implementation to fulfill the
specification and while it is there that data was exported. Delphi used
to have a compiler switch to include RTTI. (If I remember correctly
without the compiler switch the pointer to RTTI was simply null.) Do you
think that is an option? I figure if a third party library wanted it's
classes to be reflected at runtime they would compile their code with
that switch on. I don't quite know what your use-case is. For object
serialization in Java there is an interface that has to be implemented.
This would be similar to the @reflected annotation bearophile mentioned,
because it is mostly a tag. RTTI for specific classes is not useless at
all. I have a module with a lot of classes in a flat hierarchy. They are
the typical case of several "commands" inheriting from a base
class/interface declaring an "execute" method and such. Since I have the
complete list of commands I could annotate them all with @reflected to
set their properties from some XML definition.
The usefulness of an annotation based RTTI depends solely on how many
use cases it can cover. It doesn't hurt anyone who doesn't want to use
it. The same goes for the compiler switch. Full reflection like in Java
... oh wait. Do you plan on writing a debugger? That's the only use case
I can come up with right now?
- Marco
It would help for my serialization library. Currently I can only get/set
fields based on compile time strings via .tupleof. Currently I'm looping
over the tuple and calling the archive, like: "given me the value of
field 'foo'". Instead the archive could run through the data and to
something this: "ok, now I'm at field 'foo', I'm just setting the value
of the field".
--
/Jacob Carlborg