On Wed, 16 Nov 2005 09:44:53 +0100, dennis luehring <dl.soluz@gmx.net> wrote:
>> Maybe, but also trivial to add yourself if you want.
>
> this is the perfect example of how i would (must) do it
>
>> import std.stdio;
>>  enum COLOR { RED, GREEN, BLUE }
>> const char[][COLOR] map;
>>  static this()
>> {
>>   map[COLOR.RED] = "the color red";
>>   map[COLOR.GREEN] = "the color green";
>>   map[COLOR.BLUE] = "the color blue";
>> }
>>  //assert required because COLOR
>> char[] toString(COLOR c) { assert(c <= COLOR.BLUE); return map[c]; }
>>  void main()
>> {
>>   COLOR c = COLOR.RED;
>>   writefln(toString(c));
>> }
>>  Regan
>
> why not in fewer lines of code (= fewer lines of errors)
>
> an why should i seperate my key (your enum) and my data (your map) over (in your very tiny tiny small example) 7 lines of code
>
> what if use an huge amount of different enums (with different types referecing to) - how big(more buggy) is my code then?

I agree that seperating the key/value data can increase the chance of bugs, that is why I put them both in the same place in my code, it's a defensive programming habit which we should all have. I agree, you can improve this even further if the compiler verifies you have entered all your keys and values, perhaps with one of the syntaxes you mention.

In the end however, it can already be done, the downside is almost insignificant and there are bigger fish to fry! Perhaps later on when Walter runs out of things to fix he'll look at adding a nice sugary syntax for this sort of thing.

Regan

dennis luehring wrote:
>> Maybe, but also trivial to add yourself if you want.
> 
> 
> this is the perfect example of how i would (must) do it
> 
>> import std.stdio;
>>
>> enum COLOR { RED, GREEN, BLUE }
>> const char[][COLOR] map;
>>
>> static this()
>> {
>>   map[COLOR.RED] = "the color red";
>>   map[COLOR.GREEN] = "the color green";
>>   map[COLOR.BLUE] = "the color blue";
>> }
>>
>> //assert required because COLOR
>> char[] toString(COLOR c) { assert(c <= COLOR.BLUE); return map[c]; }
>>
>> void main()
>> {
>>   COLOR c = COLOR.RED;
>>   writefln(toString(c));
>> }
>>
>> Regan
> 
> 
> why not in fewer lines of code (= fewer lines of errors)
> 
> an why should i seperate my key (your enum) and my data (your map) over (in your very tiny tiny small example) 7 lines of code
> 
> what if use an huge amount of different enums (with different types referecing to) - how big(more buggy) is my code then?
> 
> // i use the syntax from BCS (post above)
> const char[] enum COLOR
> {
>   RED : "the color red",
>   GREEN : "the color green",
>   BLUE : "the color blue"
> }
> 
> void main()
> {
>   COLOR c = COLOR.RED; // means c.key = COLOR.RED
>   writefln(c.value);
> }
> 
> ok i know the syntax isn't very clear defined...

I've taught CS classes on graduate level for yeras. This is a very common thing to ask for.

Then again, when doing professional programming, few people ask for this.

---

It seems that enum usage examples in coursebooks often use things like:

enum FOO {JAN, FEB, MAR}
FOO now;

// here some code to do something instructive :-)

... // later:

switch (now)
{
    JAN : writefln("January"); break;
    FEB : writefln("February"); break;
}

All of this creates an atmosphere where people think enums are somehow meant to be associated with strings that describe their name.

Some of my students have later commented that what remains from having done the schoolbook enum excercises, is a feeling that "they are a contrived way of choosing between alternative outputs". Probably because that is what one sees when one runs such programs, and also because most of the effort (at that skill level) goes to getting the program to compile -- thus diverting attention from the few lines where enums got used for something.

I guess a more productive way of teaching enums would be to create exercises in the previous chapter (which teaches some other subject) so that students' code ends up looking like:

...
const int FRIEND   = 1;
const int RELATIVE = 2;
const int OTHER    = 3;
...

And then in the next chapter introduce a shorter way of writing this, with the cool side effect of added type safety:

enum PersonStatus {FRIEND, RELATIVE, OTHER}
...
PersonStatus mobster;
...
if (mobster == OTHER) {run for your life}

Another common use of enums is to store properties in a size efficient and (for the computer) easy to use way:

enum Need
{
    NOTHING = 0,    // ain't that the day!
    FOOD    = 1,    // nourishment needed
    SHELTER = 2,    // a place to sleep in
    MEDIC   = 4,    // health needs attention
    MATE    = 8,    // the person is lonely
}
...
struct Person
{
    Need needs = NOTHING;
    void newNeed(Need grief) {needs |= grief;}
    bool isLacking(Need what) {return needs & what;}
    bool isPathetic() {return needs == FOOD|SHELTER|MEDIC|MATE;}
}

As to the OP, a more constructive way of using enum COLOR would be something like:

enum Color
{
    RED = 0xff0000,
    GREEN = 0x00ff00,
    DARKGREY = 0x404040,
}

nice answer but don't get me wrong im not talking about enum_string or something (because im not one of these unprof. devlopers. - im an very very defensiv programmer)

i talk about the syntactic sugar of merging some enum features with maps (just to reduce the amount of code (and errors)) while writing mapping stuff

the internal key should be stay int, but the second value should be defineable

example for an answer which goes in the right direction:
news://news.digitalmars.com:119/ops0bzpwgc23k2f5@nrage.netwin.co.nz

ciao dennis

In article <ops0bzpwgc23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Wed, 16 Nov 2005 09:44:53 +0100, dennis luehring <dl.soluz@gmx.net> wrote:
>>> Maybe, but also trivial to add yourself if you want.
>>
>> this is the perfect example of how i would (must) do it
>>
>>> import std.stdio;
>>>  enum COLOR { RED, GREEN, BLUE }
>>> const char[][COLOR] map;
>>>  static this()
>>> {
>>>   map[COLOR.RED] = "the color red";
>>>   map[COLOR.GREEN] = "the color green";
>>>   map[COLOR.BLUE] = "the color blue";
>>> }
>>>  //assert required because COLOR
>>> char[] toString(COLOR c) { assert(c <= COLOR.BLUE); return map[c]; }
>>>  void main()
>>> {
>>>   COLOR c = COLOR.RED;
>>>   writefln(toString(c));
>>> }
>>>  Regan
>>
>> why not in fewer lines of code (= fewer lines of errors)
>>
>> an why should i seperate my key (your enum) and my data (your map) over (in your very tiny tiny small example) 7 lines of code
>>
>> what if use an huge amount of different enums (with different types referecing to) - how big(more buggy) is my code then?
>
>I agree that seperating the key/value data can increase the chance of bugs, that is why I put them both in the same place in my code, it's a defensive programming habit which we should all have. I agree, you can improve this even further if the compiler verifies you have entered all your keys and values, perhaps with one of the syntaxes you mention.
>
>In the end however, it can already be done, the downside is almost insignificant and there are bigger fish to fry! Perhaps later on when Walter runs out of things to fix he'll look at adding a nice sugary syntax for this sort of thing.

Hope he does, I've been longing for this feature in high level languages for a long time. It would be nice (and I suppose no performance waste would occur also).

Tom

> I agree that seperating the key/value data can increase the chance of  bugs,  that is why I put them both in the same place in my code,

but this will not help if the code rots over years
(under the change of many stressed and poor expirienced programmers)

> it's a defensive programming habit which we should all have. 

under the right conditions :-) (see above statement)

> I agree, you can
> improve this even further if the compiler verifies you have entered all  your keys and values, perhaps with one of the syntaxes you mention.

thanks for beeing the first who understand what i want(mean)

> In the end however, it can already be done, the downside is almost  insignificant and there are bigger fish to fry! 
> Perhaps later on when
> Walter runs out of things to fix he'll look at adding a nice sugary syntax  for this sort of thing.

hope will never die

ciao dennis