Chances of D getting proper runtime reflection?

[Jacob Carlborg]

On 2011-08-21 14:55, Marco Leise wrote:
> Am 21.08.2011, 14:11 Uhr, schrieb Jacob Carlborg <doob at 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