could be a nice feature for string / object (and other) mappings

normaly:
[int] enum color { red, green, blue }

what about other types? like

char[] enum color { red="the color red", green="the color green", blue="the color blue" }

for direkt mapping of string or other values? better than

enum color{ red, green, blue }
char[] color_str[color.size]=["the color red", "the color green", "the color blue"]

usefull?

dennis luehring wrote:
> could be a nice feature for string / object (and other) mappings
> 
> normaly:
> [int] enum color { red, green, blue }
> 
> what about other types? like
> 
> char[] enum color { red="the color red", green="the color green", blue="the color blue" }
> 
> for direkt mapping of string or other values? better than
> 
> enum color{ red, green, blue }
> char[] color_str[color.size]=["the color red", "the color green", "the color blue"]
> 
> usefull?
> 
> 

"only as an more-handy feature"
something like an per-const-symbol-referenceable map (with fix int based key and variable value)

in c++: map<int, string> color
maybe in d: char[] enum color { red, green, blue }

i can code this with consts and strings in c++/d like this

const char[] red = "the red color";
const char[] green = "the green color";
const char[] blue = "the blue color";

but i lost the color scope

dennis luehring wrote:
> could be a nice feature for string / object (and other) mappings
> 
> normaly:
> [int] enum color { red, green, blue }
> 
> what about other types? like

You can use any of the built-in types you want (but not arrays of built-in types)

enum : ushort color
{
}

enum : char color
{
}

and so on

> 
> char[] enum color { red="the color red", green="the color green", blue="the color blue" }
> 
> for direkt mapping of string or other values? better than
> 
> enum color{ red, green, blue }
> char[] color_str[color.size]=["the color red", "the color green", "the color blue"]
> 
> usefull?

I don't see strings as enums being useful. What would be the default values? How would you implement auto incrementation of default values? If you really want strings, and not enumerated values, then an array of strings will get you what you want in this case.

What *would* be useful would be a way to convert enum values to strings automatically, i.e. color.red converts to "red" or "color.red", through a function call.

Mike Parker wrote:
> dennis luehring wrote:
[]
> I don't see strings as enums being useful. What would be the default values? How would you implement auto incrementation of default values? If you really want strings, and not enumerated values, then an array of strings will get you what you want in this case.
> 
> What *would* be useful would be a way to convert enum values to strings automatically, i.e. color.red converts to "red" or "color.red", through a function call.

I agree completely: it's always annoying to display number for enums to the user, or to do the conversion by hand.

The only annoying part of enum to string is that as you've said, there are at least two different conversion: red or color.red, and maybe module_name.color.red would be useful also.

It's isn't a major issue, one should be picked at the default (my vote goes to color.red) and the other ones accessible with an additionnal parameter: to_string(short), to_string(full) for example.

On one hand it adds 'syntaxic sugar' only for enum (I don't see how this could be reused elsewhere), on the other hand enums are important.

Regards

This is just a hack for the syntax but how about something like this:

|enum X
|{
|  A = 1 : "The letter A\n" ,
|  B : "The next Letter",
|  C : "Bla Bla Bla"
|};

where something like

| wrietf(X.A.toString)

prints out "The letter A\n" and

| X a = X.B
| wrietf(a.toString)

prints out "The next Letter". This could be implemented with a hidden static array of some type.

e.g.

| X a = X.B
| wrietf(a.toString)

becomes

| X a = X.B
| wrietf(X.hiddenArray[a])




In article <dlbv5c$beo$1@digitaldaemon.com>, renox says...
>
>Mike Parker wrote:
>> dennis luehring wrote:
>[]
>> I don't see strings as enums being useful. What would be the default values? How would you implement auto incrementation of default values? If you really want strings, and not enumerated values, then an array of strings will get you what you want in this case.
>> 
>> What *would* be useful would be a way to convert enum values to strings automatically, i.e. color.red converts to "red" or "color.red", through a function call.
>
>I agree completely: it's always annoying to display number for enums to the user, or to do the conversion by hand.
>
>The only annoying part of enum to string is that as you've said, there are at least two different conversion: red or color.red, and maybe module_name.color.red would be useful also.
>
>It's isn't a major issue, one should be picked at the default (my vote goes to color.red) and the other ones accessible with an additionnal parameter: to_string(short), to_string(full) for example.
>
>On one hand it adds 'syntaxic sugar' only for enum (I don't see how this could be reused elsewhere), on the other hand enums are important.
>
>Regards

BCS wrote:
> This is just a hack for the syntax but how about something like this:
> 
> |enum X
> |{
> |  A = 1 : "The letter A\n" ,
> |  B : "The next Letter",
> |  C : "Bla Bla Bla"
> |};

nice idea - but the value type should be defineable

your example "char[] enum X"

int[3] enum X
{
  A = 1 : [1,2,3],
  B : [67,23,21],
  C : [21,22,33]
}

> where something like
> 
> | wrietf(X.A.toString)

writef(X.A.value) would be better (what if the type is int[3] :-))

ciao dennis

BCS wrote:

> This is just a hack for the syntax but how about something like this:
> 
> |enum X
> |{
> |  A = 1 : "The letter A\n" ,
> |  B : "The next Letter",
> |  C : "Bla Bla Bla"
> |};

I think that both Mike Parker and I thought more about something like this:

enumstr X { A, B, C };
X x = A;

Where x.toString returns "X.A", x.toString(short_name) returns "A", x.toString(full_name) returns "module_name.X.A".

Your solution and that of dl.soluz@gmx.net are more flexible but also necessitate more typing in the common case (just writing a *readable* trace file) i.e: enum X { THE_LABEL: "X.THE_LABEL" } and these generic solution do not allow the short_name, full_name 'hack', I think..

Regards,
RenoX


> 
> where something like
> 
> | wrietf(X.A.toString)
> 
> prints out "The letter A\n" and 
> 
> | X a = X.B
> | wrietf(a.toString)
> 
> prints out "The next Letter". This could be implemented with a hidden static array of some type.
> 
> e.g.
> 
> | X a = X.B
> | wrietf(a.toString)
> 
> becomes
> 
> | X a = X.B
> | wrietf(X.hiddenArray[a])
> 
> 
> 
> 
> In article <dlbv5c$beo$1@digitaldaemon.com>, renox says...
> 
>>Mike Parker wrote:
>>
>>>dennis luehring wrote:
>>
>>[]
>>
>>>I don't see strings as enums being useful. What would be the default values? How would you implement auto incrementation of default values? If you really want strings, and not enumerated values, then an array of strings will get you what you want in this case.
>>>
>>>What *would* be useful would be a way to convert enum values to strings automatically, i.e. color.red converts to "red" or "color.red", through a function call.
>>
>>I agree completely: it's always annoying to display number for enums to the user, or to do the conversion by hand.
>>
>>The only annoying part of enum to string is that as you've said, there are at least two different conversion: red or color.red, and maybe module_name.color.red would be useful also.
>>
>>It's isn't a major issue, one should be picked at the default (my vote goes to color.red) and the other ones accessible with an additionnal parameter: to_string(short), to_string(full) for example.
>>
>>On one hand it adds 'syntaxic sugar' only for enum (I don't see how this could be reused elsewhere), on the other hand enums are important.
>>
>>Regards
> 
> 
> 

On Sun, 13 Nov 2005 17:33:30 +0100, dennis luehring <dl.soluz@gmx.net> wrote:
> could be a nice feature for string / object (and other) mappings
>
> normaly:
> [int] enum color { red, green, blue }
>
> what about other types? like
>
> char[] enum color { red="the color red", green="the color green", blue="the color blue" }
>
> for direkt mapping of string or other values? better than
>
> enum color{ red, green, blue }
> char[] color_str[color.size]=["the color red", "the color green", "the color blue"]
>
> usefull?

Maybe, but also trivial to add yourself if you want.

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

> I think that both Mike Parker and I thought more about something like this:
> 
> enumstr X { A, B, C };
> X x = A;
> 
> Where x.toString returns "X.A", x.toString(short_name) returns "A", x.toString(full_name) returns "module_name.X.A".

but this is for the "we need a reflection system in d" section
(for example i would like to have (class,method,variable,enum,...).name or something like this (only) avaiable at compiletime

> Your solution and that of dl.soluz@gmx.net are more flexible but also necessitate more typing in the common case (just writing a *readable* trace file) i.e: enum X { THE_LABEL: "X.THE_LABEL" } and these generic solution do not allow the short_name, full_name 'hack', I think..

i just want an enum-likeish stlye of data mapping (scope of const-symbols referencing to something with key/value ...)

- the reflection or "code information" stuff is another section...

ciao dennis

> 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);
}

or as an array of ints

const int[3] enum COLOR
{
  RED : [12,0,331],
  GREEN : [10,11,0],
  BLUE : [3,2,41]
}

void main()
{
  COLOR c = COLOR.RED; // means c.key = COLOR.RED
  int[] values = c.value;
}

ok i know the syntax isn't very clear defined...