Design of reflective enums

[renoX]

Kevin Bealer Wrote:
> 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.
> > - then the printable label feature should be as simple to use as possible: this feature will  probably be used much more often than the foreach feature.
> > 
> > For the API, the functions needed are:
> > a- Reflective Enum(REnum) list definition.
> > b. REnum variable definition.
> > c. Reference to an REnum label.
> > d. Print the label corresponding to the value of an REnum variable.
> > e. Iterate over all possible value in an REnum list.
> > f. Iterate over all possible labels in an REnum list (I've added this one by symmetry).
> > 
> > (a) Takes a name and either define (1) an enum of this name plus some functions to print enum labels and iterate over it, or alternatively as in the original code it can return a 'thing' (struct for example as it in the initial implementation) (2) which contain the enum and functions.
> > I'm not sure which is best.
> > 
> > (e) and (f) reminds me of associate arrays, maybe a function to generate an associative array from the enum list would be enough..
> > 
> > I'm trying to create functions to (e) and (f), but I have trouble to make my code work currently: debugging template code is not very easy..
> > 
> > renoX
> > 
> 
> Your comment about e and f matches something I've been thinking.  The 
> action of iterating over the enum and in fact looking up the string are
> essentially similar to an associative array.  Imagine these two 
> definitions in regular D:
> 
> enum Xyz_t {
>     x = 10,
>     y = 100,
>     z = 201
> };
> 
> char[][Xyz_t] Xyz_t_lookup;
> lookup[x] = "x";
> lookup[y] = "y";
> lookup[z] = "z";
> 
> Xyz_t[] Xyz_t_keys = Xyz_t_lookup.keys;
> char[][] Xyz_t_labels = ["x", "y", "z"];
> 
> Now, I can do all the above operations with these definitions.

Agreed, in fact we don't need toString functions, the arrays are enough.

[cut]
> In principle, switch/case should be more or less always be faster than 
> actual AAs.

I must admit that I don't know at all what will be faster at runtime, but in some case the switch/case can be done at compile-time, which is a win.

Also if efficiency is a concern, I wonder if it would be useful if in the case when there is no '=' in the enum definition (a not so rare case), we could use a regular array for the lookup (lookup == labels) , the only problem then is that we'd loose type safety for the lookups..

renoX