Design of reflective enums

[renoX]

Andrei Alexandrescu (See Website For Email) a écrit :
> renoX wrote:
>> Hello,
>> Kevin Bealer has started an implementation (two implementations in 
>> fact!) of reflective enums, and I wanted to discuss the use case and 
>> the design of this feature to make it as useful as possible.
>> Reflective enums have two useful properties that don't have normal enums:
>> - their label is printable
>> - it's possible to do a foreach on all the possible values.
>>
>> In my opinion, for the reflective enums, the following constraint 
>> should apply:
>> - they should 'look like' normal enums as much as possible.
> 
> Why?

Because that way a programmer used to normal enums can use reflective 
enums nearly identically.

> There is so much more freedom now, why limit ourselves. I think 
> enums of arbitrary types should be allowed, including arrays, hashes, 
> and user-defined types.

This would be a possible extension, but I wonder if it wouldn't be a bit 
redundant with associative array..

And I think that with the current implementation, it's would be very 
difficult,as we do our own parsing which is of course quite limited.

Mmm, with this extension, my idea of reusing the built-in enum type 
doesn't work..
Kevin Bealer's implementation would work.. I'll try to tweak it to see 
if it's possible to make it feel more enum-like.

> An enumerated type is nothing but a closed set of named values. The 
> names are always strings; the values can be of any (uniform) type.

The names are not arbitrary strings but names/symbol: I wonder if a 
basic type 'symbol' would be interesting..

renoX




> 
> 
> Andrei