View mode: basic / threaded / horizontal-split · Log in · Help
November 16, 2005
Re: what about typed enums?
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
November 16, 2005
A word about Typed Enums
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,
}
November 16, 2005
Re: A word about Typed Enums
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
November 16, 2005
Re: what about typed enums?
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
November 16, 2005
Re: what about typed enums?
> 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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home