Metacode mechanics

Don Clugston dac at nospam.com.au
Fri Mar 3 05:23:33 PST 2006


Bruno Medeiros wrote:
> Don Clugston wrote:
>> Craig Black wrote:
>>>
>>> Compile-time reflection would be very nice.  I'm not sure I 
>>> understand why array literals would be a requirement for this.  Am I 
>>> missing something?
>>
>> It's because we can't have compile-time constant folding of [], except 
>> for char arrays, until we get array literals. Compile-time reflection 
>> _could_ be done without using arrays, but I think it's the most 
>> natural way of doing it, anything else would require new syntax or be 
>> a bit clunky?
>  >
> 
> Why would it requite clunky syntax? I don't see why array literals would 
> affect this. How exactly are you thinking compile-time reflection should 
> work? (in terms of usage)

Just because an array lookup can't be done at compile time.

Suppose the compiler gave you:

const char [][] members = ["func1", "func2", "func3"];

and then you want to say
const char [] secondone = members[2];

this won't be implemented until we get array literals.

> In fact I don't see how compile-time reflection could work at all 
> (regardless of array literals). I tried to convert my runtime reflection 
> example in the Reflection thread, but some things wouldn't work, one of 
> which being that one cannot use a TypeInfo as a type (for instance in a 
> declaration or something).

You don't need TypeInfo at compile time. You already have typeof, which 
is better. (You also have mangleof, which lets you get function 
parameters, etc, which is something you can't currently do at runtime).

Compile-time reflection is much better than runtime. Think about it -- 
the only time you need runtime reflection is when dynamically loading an 
external module. If you're reflecting something that's in your own exe, 
you could do it at compile time.
If you had compile-time reflection, you could do run-time reflection as 
a library, at compile time you just collect and save all the info you want.




More information about the Digitalmars-d-dtl mailing list