compile time class introspection?

[Christopher Wright]

Chris Nicholson-Sauls wrote:
> Serg Kovrov wrote:
>> janderson wrote:
>>> I disagree, I think an orthogonal design like D is a good thing in 
>>> many cases.  It means that you don't have to learn so many keywords 
>>> and are more likely to determine the syntax yourself.  It also means 
>>> code is generally easier to maintain due to generalization because 
>>> you can often   reuse the code in more different ways then originally 
>>> intended.
>>>
>>> I don't regard the solution given as a hack it seems pretty obvious 
>>> to me.  Either way it would have to be documented.  If you don't like 
>>> it, write a wrapper template.
>>>
>>> Also I don't think good orthogonality means the language has to get 
>>> more complex.  I think its about making the common coding primitives 
>>> easy to use however also making them powerful enough if the user 
>>> wants to extend them to something that is less common.
>>>
>>> -Joel
>>
>> I'm not sure I understand what you mean by "orthogonal design", and 
>> what it has to do with code reuse? I was talking about language 
>> facilities, something not available as user or library code.
>>
>> I just want to say I like idea of language features to be thoughtfully 
>> designed, as opposite to accidentally discovered side-effects. I have 
>> to say I don't really care about actual origin of a feature, but 
>> rather what it feels like.
>>
>> -- serg.
> 
> I'm not positive that the side-effect in this case at least was 
> accidental.  I seem to recall it was specifically made sure to work in 
> the development of is() expressions.  (Could be wrong, it might've been 
> talked about later.)  That said, I do hear you, and actually personally 
> wish reflection capabilities had their own access point of some kind. 
> I'd even live with a new keyword to activate that access -- in my 
> opinion it'd be worth it.
> 
> Maybe a typeinfo() primitive alongside typeof() and typeid()... although 
> that might be misleading since the objects returned by typeid() are 
> descendants of the class TypeInfo; heh.
> 
> Or maybe just the obvious reflect(), which would return an object like 
> typeid() does, but a TypeView or TypeInspect or somesuch.  Then provide 
> reflection capabilities by way of that special class.
> 
> In respect to that, maybe there should be an equivelant 'reflected' or 
> 'reflect' (note the missing parentheses) attribute for marking a class 
> as available for reflection.  That way we only include the extra 
> information in cases where its deemed useful...
> 
> And now I'm at the point where I really should have started a new 
> thread.  So I'll shut up now.  :)

Why not just improve .classinfo and apply it to structs as well? You'd 
want to rename it, probably...but if vtbl were an associative array of 
functioninfo[char[]] instead of a void*[], with a functioninfo 
definition including:
  - argument type tuple / array
  - return type
  - protection
  - static / nonstatic
  - pointer to classinfo, or null if it's a free function
  - pointer to the function

Overload opAssign so you can reassign functions at need, maybe, and then 
keep the pointer as read-only externally.

Do something similar with the members.

Of course flectioned does this. And flectioned is pretty much what the 
builtin reflection of D should hope to be.