Chances of D getting proper runtime reflection?

[Jakob Ovrum]

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.

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.