"Bill Baxter" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Tue, Nov 25, 2008 at 11:48 AM, Ary Borenszweig <[EMAIL PROTECTED]> 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.
