Unification and extension of compile-time reflection

Nick Sabalausky a at a.a
Tue Nov 25 02:55:31 PST 2008


"Bill Baxter" <wbaxter at gmail.com> wrote in message 
news:mailman.54.1227583827.22690.digitalmars-d at puremagic.com...
On Tue, Nov 25, 2008 at 11:48 AM, Ary Borenszweig <ary at esperanto.org.ar> 
wrote:
>> I liked the way you wrote this. :-)
>>
>> I think neither __traits nor a property is good enough for compile-time
>> reflection. I think just one property is enough.
>>
>> For example in Java you do:
>>
>> someInstance.getClass()
>>
>> and then you enter "the reflection world", which uses the same language 
>> as
>> Java, but it's at a different level.
>>
>> So:
>>
>> var.reflect
>>
>> or something like that would be awesome. Then you can do:
>>
>> - something.reflect.methods
>> - something.reflect.isVirtual
>> - something.reflect.isAbstract
>> - something.reflect() // same as something.reflect.compileTimeValue
>> - something.reflect.fields
>> - etc.
>>
>> So you just don't allow "reflect" (or whatever) as a field name (if you
>> define it, it's an error, much like "sizeof"), but once you enter 
>> "reflect"
>> the compiler can add as many name as it wants, nobody can override these.
>> "reflect" is smart so that for an expression, it return a specific
>> (compile-time) type; for classes, another (compile-time) type; for
>> variables, another (compile-time) type; etc.
>
>Or you could just call it traits.
>
>something.traits.methods
>something.traits.max
>something.traits.sizeof
>(1+34.).traits.typeof
>
>I do like the general idea of unifying this stuff.  Can you make an
>alias or variable of this .traits/.reflect type?  Can it return a
>metaclass type of some sort so that an alias would be possible?  I.e.
>alias t = something.traits;
>

That would make it much easier to port over Java code that uses reflection. 
And even aside from that, I think it's a very nice and clean solution. 





More information about the Digitalmars-d mailing list