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 <d...@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

Reply via email to