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