compile time class introspection?

[Chris Nicholson-Sauls]

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.  :)

-- Chris Nicholson-Sauls