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

I've ran into trouble trying to implement the associative array: apparently it's not possible to build an associative array at compile time.

Added to that the fact that overloading of functions doesn't work correctly on enums, the implementation of good reflective enum starts to look really difficult..

So it's a choice between
-using your initial implementation, which is not typesafe..
-restricting reflective enums to enums without '=' ie with values going 0,1,2..
-waiting that Walter fix the current limitations on associative arrays or the bug(?) on function overloading with enums (overloading with a typedef has the same issue, so maybe it's me who doesn't understand the overload behaviour?)..


:-(
renoX

renoX wrote:
> I've ran into trouble trying to implement the associative array: apparently it's not possible to build an associative array at compile time.
> 
> Added to that the fact that overloading of functions doesn't work correctly on enums, the implementation of good reflective enum starts to look really difficult..
> 
> So it's a choice between
> -using your initial implementation, which is not typesafe..
> -restricting reflective enums to enums without '=' ie with values going 0,1,2..
> -waiting that Walter fix the current limitations on associative arrays or the bug(?) on function overloading with enums (overloading with a typedef has the same issue, so maybe it's me who doesn't understand the overload behaviour?)..
> 
> 
> :-(
> renoX

I want to make clear -- efficiency is important to me, at least if this is to be a replacement for enum, efficiency should be as much as is attainable, which should be a lot if it happens at compile time.

Just to clarify my previous idea, when I say 'CTAA', I don't mean building a real AA at compile time.  I mean building something that works like an AA as far as lookups, but the contents are readonly and added to the container at compile time.  My idea is to get maximal efficiency of the type that most likely can't be had with a real AA.

The ultimate efficiency in this case would be to have *lookup* happen at compile time for users of the class, though this can only happen in those cases where the search term is constant at compile time.  In other cases, something like a switch would be my preference.

Of course for the case of a reflective enum, looking up the label is probably not too common so it could be done some other way, but I'm thinking the CTAA should be as fast as possible.  What I'm imagining is something like this:

CTAA!("dog, bear, cat, snake, whiskey, soda") foo;

const char[] x = foo.find!("dog")(); // A
const char[] x = "bear";             // B

My hope is for a design where statement A is transformed into statement B at compile time.

Kevin

Andrei Alexandrescu (See Website For Email) wrote:
> On the contrary, I think it would be great if it were _not_ in the core language, and I'd be happy if a library enum was so good, it would cause deprecation of the built-in one.

It's a great idea! But there are few issues that should be addressed:

1. Library implementation of enums should be able to produce a typedef, just like built-in enums.

2. Built-in enums do not produce symbols in object files. Neither should library implementation.

-- 
serg.

Serg Kovrov a écrit :
> Andrei Alexandrescu (See Website For Email) wrote:
>> On the contrary, I think it would be great if it were _not_ in the core language, and I'd be happy if a library enum was so good, it would cause deprecation of the built-in one.
> 
> It's a great idea! But there are few issues that should be addressed:
> 
> 1. Library implementation of enums should be able to produce a typedef, just like built-in enums.

This is doable, unfortunately function overload on typedef/enum seems broken, so..

> 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..

renoX

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.

-- 
Michiel

Michiel a écrit :
> 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.

renoX

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.

-- 
Michiel

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/