View mode: basic / threaded / horizontal-split · Log in · Help
November 13, 2005
what about typed enums?
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?
November 13, 2005
Re: what about typed enums?
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
November 14, 2005
Re: what about typed enums?
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.
November 15, 2005
Re: what about typed enums?
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
November 15, 2005
Re: what about typed enums?
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
November 15, 2005
Re: what about typed enums?
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
November 15, 2005
Re: what about typed enums?
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
> 
> 
>
November 15, 2005
Re: what about typed enums?
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
November 16, 2005
Re: what about typed enums?
> 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
November 16, 2005
Re: what about typed enums?
> 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...
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home