Chances of D getting proper runtime reflection?

Jacob Carlborg doob at me.com
Sun Aug 21 11:29:41 PDT 2011


On 2011-08-21 18:18, Jakob Ovrum wrote:
> On 2011/08/21 22:13, Vladimir Panteleev wrote:
>> On Sun, 21 Aug 2011 15:16:11 +0300, Jacob Carlborg <doob at me.com> wrote:
>>
>>> Yes, I know. But the point is to be able to do it without the use of
>>> mixins. It needs to work with third party types, otherwise there no
>>> use. It also needs to work when the static type is Object.
>>>
>>> You're already paying for the class info, which already contains
>>> getMembers. But this methods always returns an empty array and as far
>>> as I can see, it's not possible to set/get fields or call methods via
>>> these member instances.
>>
>> I think the best way to do this is to improve compile-time reflection to
>> the point where it'd be possible to enumerate all declarations in a
>> module and create run-time reflection information for them - then you'd
>> just need to specify the modules for which you'd like run-time
>> reflection. One thing to note is that there are use cases where more
>> run-time information about a program's internals may not be desired,
>> e.g. with commercial closed-source applications, so this would need to
>> be optional.
>>
>
> I definitively think this is the way to go forward.
>
> The only situation this method doesn't handle is the case of only having
> D interface files and binaries for a library you want to serialize.
> However, if the library is closed-source, one of the reasons for that
> might be that they don't want this kind of information to be available,
> and if that's the case and D would generate this runtime information by
> default, we'd start seeing obfuscators for D as which break the
> reflection functionality.

The information is already available via .tupleof. This would make it 
available through base class references and with runtime strings.

> As for the other way around, where a closed-source library wanted to
> retain runtime reflection capabilties, they could always include the
> information by explicitly instantiating the runtime information template
> or however it would be implemented.
>
> Besides, compile-time reflection for entire modules has many uses beyond
> implementing runtime reflection.


-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list