Design of reflective enums

Daniel Keep daniel.keep.lists at gmail.com
Sat Feb 24 04:19:23 PST 2007



Michiel wrote:
> renoX wrote:
> 
>>>>> 2. Built-in enums do not produce symbols in object files. Neither
>>>>> should library implementation.
>>>> Well for reflective enums, you need to store the strings somewhere..
>>> Not if it's a core feature. Every request for a label could be replaced
>>> by a literal by the compiler.
>> I think that we do not understand, I'm talking about 'reflective enums'
>> not regular enums (after all the thread is 'design of reflective enums).
>>
>> Reflective are enums where you can print also the *label* associated
>> with the enum, so there must be a function somewhere which have these
>> label strings to be able to print the label at runtime.
>> So the label strings must be of course stored in the binary for
>> reflective enums.
> 
> Yes, but it wouldn't be a symbol. Like I said, a request for a label
> could be replaced by a string literal by the compiler IF reflective
> enums were a core language feature.

The key here is *at runtime*.

enum CompressionLevel
{
    None = 0,
    Minimal = 1,
    Normal = 2,
    Maximal = 3
}

{
    CompressionLevel cl = some_function();
    writefln( toFullString(cl) );
}

In order for the toFullString function to work, the string must be
stored somewhere in the executable so that it is accessible at runtime.

At least, I think that's what renoX is talking about :3

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/



More information about the Digitalmars-d mailing list