Signals and Slots in D

Walter Bright newshound at digitalmars.com
Fri Sep 29 10:23:34 PDT 2006


Don Clugston wrote:
> The most basic introspection would simply be, for each class and struct 
> Typeinfo, add a pointer to a string that's just a concatenation of names 
> and mangled types.
> [name]\0[mangleof]\0[name]\0[mangleof]\0...[name]\0[mangleof]\0\0.
> Since we have .alignof and .sizeof, this would allow all data members to 
> be identified; and would allow code to be developed that could do 
> serialization stuff. It would also be reasonably compact.
> And an identical treatment for the functions in the vtable (just need to 
> maintain the same order of functions). Given a string XXX, you could 
> search for a function named "slotXXX" in the manglelist, and call the 
> corresponding entry in the vtable.

I think generating an array of TypeInfo's would be better, because 
they're easier to manipulate. TypeInfo instances are also singletons, 
which potentially could make it smaller than the mangle strings.

3 pieces of info are needed for each member:

name
typeinfo
offset

> It wouldn't deal with static functions (where you need the address as 
> well as the name and type info)
> I guess the challenging issue is to make sure that functions that aren't 
>  referenced don't get type info stored? I imagine those dynamic 
> languages have trouble discarding unused functions at link time. I think 
> you'd need to tell the compiler "don't discard this function even if you 
> think it's not used, it's only referenced in a text string".

The bloat might be bad enough that the full introspection info would
only be generated for specified classes, say, ones that inherit from a 
special
interface class.



More information about the Digitalmars-d mailing list