www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Getting the string representing the enum value

reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
say I have an enum

     enum X
     {
      A,
      B,
      C
     }

and I have

     void someFunc( X e )
     {
      //.. some code
     }

I want to print the value of 'e' but I don't want to get a number!! I 
want to get a string that represents it. i.e. A or B or C


     void someFunc( X e )
     {
        toString(e);
        e.string;
        e.value;
        //or something like that ..
     }

Is there any such thing in D?
Apr 01 2006
next sibling parent Victor Nakoryakov <nail-mail mail.ru> writes:
Hasan Aljudy wrote:

 say I have an enum
 
     enum X
     {
      A,
      B,
      C
     }
 
 and I have
 
     void someFunc( X e )
     {
      //.. some code
     }
 
 I want to print the value of 'e' but I don't want to get a number!! I 
 want to get a string that represents it. i.e. A or B or C
 
 
     void someFunc( X e )
     {
        toString(e);
        e.string;
        e.value;
        //or something like that ..
     }
 
 Is there any such thing in D?
 


Hello,

AFAIK, there is now way to do what you want directly. Simplest solution 
is to create helper map that would have X as a key and char[] as a value 
and then to define function toString(X x) the would return string 
representation.


-- 
Victor (aka nail) Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia
Apr 02 2006
prev sibling next sibling parent Jason Mills <jmills cs.mun.ca> writes:
Hasan Aljudy wrote:

 say I have an enum
 
     enum X
     {
      A,
      B,
      C
     }
 
 and I have
 
     void someFunc( X e )
     {
      //.. some code
     }
 
 I want to print the value of 'e' but I don't want to get a number!! I 
 want to get a string that represents it. i.e. A or B or C
 
 Is there any such thing in D?
 


Sadly, no. I once suggested that enums be a little smarter, more like 
.NET enums or, even better in my opinion, Java 5 enums. Being able to 
obtain a string representation from an enum value, parsing an enum value 
from a string, and (in Java versions) attach functionality or custom 
strings to enum values, is very powerful.

If I remember correctly, the idea was rejected out right. Maybe there 
are performance issues?

Jason
Apr 02 2006
prev sibling parent reply Ben Gardner <bengardner.uncrustify gmail.com> writes:
I've done that "the hard way" in C.
Here's an example in D:

/////
import std.stdio;
import std.string;

enum X {
  Apple,
  Bat,
  Car,
}

char [][] X_names = [
   X.Apple : "Apple",
   X.Bat   : "Bat",
   X.Car   : "Car",
];

char [] get_X_name(X e)
{
   if ((e >= X.min) && (cast(int)e < X_names.length) &&
       (X_names[e] !is null)) {
      return X_names[e];
   }
   return ("invalid");
}

X get_X_id(char [] name)
{
   for (int idx = 0; idx < X_names.length; idx++) {
      if ((X_names[idx] !is null) && (icmp(X_names[idx], name) == 0))
         return cast(X)idx;
   }
   return cast(X)-1;
}

void main(char [][] args)
{
   for (int i = -1; i < 4; i++)
   {
      writef("%d = '%s'\n", i, get_X_name(cast(X)i));
   }

   char [] name = "bat";
   writef("id for '%s' is %d\n", name, cast(int)get_X_id(name));
}
////

Running this produces the output:
-1 = 'invalid'
0 = 'Apple'
1 = 'Bat'
2 = 'Car'
3 = 'invalid'
id for 'bat' is 1

Ben

Hasan Aljudy wrote:

 say I have an enum
 
     enum X
     {
      A,
      B,
      C
     }
 
 and I have
 
     void someFunc( X e )
     {
      //.. some code
     }
 
 I want to print the value of 'e' but I don't want to get a number!! I
 want to get a string that represents it. i.e. A or B or C
 
 
     void someFunc( X e )
     {
        toString(e);
        e.string;
        e.value;
        //or something like that ..
     }
 
 Is there any such thing in D?
Apr 02 2006
next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
You have the right idea, although I think it would be better to name the
X->char[] 
function 'toString' and the char[]->X function 'toX' and the map with all
capitals. 
Convention, you see, and clarity through expressions like:




In fact, if you don't want the char[]->X conversion at all, then the map can be
a static 
variable of 'toString(X)', to prevent namespace pollution.

One other suggestion: note the rewritten code below:

Ben Gardner wrote:

 I've done that "the hard way" in C.
 Here's an example in D:
 
 /////
 import std.stdio;
 import std.string;
 
 enum X {
   Apple,
   Bat,
   Car,
 }
 
 char [][] X_names = [
    X.Apple : "Apple",
    X.Bat   : "Bat",
    X.Car   : "Car",
 ];
 
 char [] get_X_name(X e)
 {
    if ((e >= X.min) && (cast(int)e < X_names.length) &&
        (X_names[e] !is null)) {
       return X_names[e];
    }
    return ("invalid");
 }


char[] toString (X value) {
   if (auto foo = value in X_NAMES)
     return *foo;
   return "invalid";
}


 X get_X_id(char [] name)
 {
    for (int idx = 0; idx < X_names.length; idx++) {
       if ((X_names[idx] !is null) && (icmp(X_names[idx], name) == 0))
          return cast(X)idx;
    }
    return cast(X)-1;
 }


X toX (char[] value) {
   foreach (id, name; X_NAMES) {
     if (icmp(name, value) == 0)
       return id;
   }
   return cast(X)-1;
}

-- Chris Nicholson-Sauls
Apr 02 2006
prev sibling parent reply kris <foo bar.com> writes:
Ben Gardner wrote:

 I've done that "the hard way" in C.
 Here's an example in D:
 
 /////
 import std.stdio;
 import std.string;
 
 enum X {
   Apple,
   Bat,
   Car,
 }
 
 char [][] X_names = [
    X.Apple : "Apple",
    X.Bat   : "Bat",
    X.Car   : "Car",
 ];
 
 char [] get_X_name(X e)
 {
    if ((e >= X.min) && (cast(int)e < X_names.length) &&
        (X_names[e] !is null)) {
       return X_names[e];
    }
    return ("invalid");
 }
 
 X get_X_id(char [] name)
 {
    for (int idx = 0; idx < X_names.length; idx++) {
       if ((X_names[idx] !is null) && (icmp(X_names[idx], name) == 0))
          return cast(X)idx;
    }
    return cast(X)-1;
 }
 
 void main(char [][] args)
 {
    for (int i = -1; i < 4; i++)
    {
       writef("%d = '%s'\n", i, get_X_name(cast(X)i));
    }
 
    char [] name = "bat";
    writef("id for '%s' is %d\n", name, cast(int)get_X_id(name));
 }
 ////
 
 Running this produces the output:
 -1 = 'invalid'
 0 = 'Apple'
 1 = 'Bat'
 2 = 'Car'
 3 = 'invalid'
 id for 'bat' is 1
 
 Ben
 
 Hasan Aljudy wrote:
 

say I have an enum

    enum X
    {
     A,
     B,
     C
    }

and I have

    void someFunc( X e )
    {
     //.. some code
    }

I want to print the value of 'e' but I don't want to get a number!! I
want to get a string that represents it. i.e. A or B or C


    void someFunc( X e )
    {
       toString(e);
       e.string;
       e.value;
       //or something like that ..
    }

Is there any such thing in D?





I'll propose that a new property be added, somewhat like the .mangleof 
property. Instead, a .nameof property would simply return the lexical 
token for the named entity. Doesn't matter whether it refers to a 
struct, class, some attribute thereof, enum types or members, whatever 
... the x.nameof should just return a char[] of the respective name.

Thoughts?
Apr 02 2006
next sibling parent reply Ben Gardner <bengardner.uncrustify gmail.com> writes:
kris wrote:

 
 I'll propose that a new property be added, somewhat like the .mangleof
 property. Instead, a .nameof property would simply return the lexical
 token for the named entity. Doesn't matter whether it refers to a
 struct, class, some attribute thereof, enum types or members, whatever
 ... the x.nameof should just return a char[] of the respective name.
 
 Thoughts?


This would be easy implement if the enum value is known at compile time
(ie, X.Apple.nameof).

But to do this for an unknown enum value would require that a complete
string table be defined for every enum.

void foo(X e)
{
   writef("the enum name is %s\n", e.nameof);
}

I suppose that the compiler would be smart enough to drop the string
table if it is never used, so there is no harm in defining the table for
all enums.

Ben
Apr 02 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Ben Gardner wrote:

 kris wrote:
 

I'll propose that a new property be added, somewhat like the .mangleof
property. Instead, a .nameof property would simply return the lexical
token for the named entity. Doesn't matter whether it refers to a
struct, class, some attribute thereof, enum types or members, whatever
... the x.nameof should just return a char[] of the respective name.

Thoughts?


 
 
 This would be easy implement if the enum value is known at compile time
 (ie, X.Apple.nameof).
 
 But to do this for an unknown enum value would require that a complete
 string table be defined for every enum.
 
 void foo(X e)
 {
    writef("the enum name is %s\n", e.nameof);
 }
 
 I suppose that the compiler would be smart enough to drop the string
 table if it is never used, so there is no harm in defining the table for
 all enums.
 
 Ben


Yeah, I think it's actually very easy to implement, I don't see why dmd 
doesn't do it.

for every enum X, the parser can very easily identify EnumMembers and 
generate a table along the lines of:

     char[] [X] XMemberToStringTable;

     static this()
     {
         XMemberToStringTable[X.A] = "A";
         XMemberToStringTable[X.B] = "B";
         XMemberToStringTable[X.C] = "C";
     }

     char[] XtoString( X a )
     {
         return XMemberToStringTable[a];
     }

not hard at all.
Apr 02 2006
prev sibling next sibling parent James Dunne <james.jdunne gmail.com> writes:
kris wrote:

 Ben Gardner wrote:
 

 I've done that "the hard way" in C.
 Here's an example in D:

 /////
 import std.stdio;
 import std.string;

 enum X {
   Apple,
   Bat,
   Car,
 }

 char [][] X_names = [
    X.Apple : "Apple",
    X.Bat   : "Bat",
    X.Car   : "Car",
 ];

 char [] get_X_name(X e)
 {
    if ((e >= X.min) && (cast(int)e < X_names.length) &&
        (X_names[e] !is null)) {
       return X_names[e];
    }
    return ("invalid");
 }

 X get_X_id(char [] name)
 {
    for (int idx = 0; idx < X_names.length; idx++) {
       if ((X_names[idx] !is null) && (icmp(X_names[idx], name) == 0))
          return cast(X)idx;
    }
    return cast(X)-1;
 }

 void main(char [][] args)
 {
    for (int i = -1; i < 4; i++)
    {
       writef("%d = '%s'\n", i, get_X_name(cast(X)i));
    }

    char [] name = "bat";
    writef("id for '%s' is %d\n", name, cast(int)get_X_id(name));
 }
 ////

 Running this produces the output:
 -1 = 'invalid'
 0 = 'Apple'
 1 = 'Bat'
 2 = 'Car'
 3 = 'invalid'
 id for 'bat' is 1

 Ben

 Hasan Aljudy wrote:


 say I have an enum

    enum X
    {
     A,
     B,
     C
    }

 and I have

    void someFunc( X e )
    {
     //.. some code
    }

 I want to print the value of 'e' but I don't want to get a number!! I
 want to get a string that represents it. i.e. A or B or C


    void someFunc( X e )
    {
       toString(e);
       e.string;
       e.value;
       //or something like that ..
    }

 Is there any such thing in D?




 
 
 I'll propose that a new property be added, somewhat like the .mangleof 
 property. Instead, a .nameof property would simply return the lexical 
 token for the named entity. Doesn't matter whether it refers to a 
 struct, class, some attribute thereof, enum types or members, whatever 
 ... the x.nameof should just return a char[] of the respective name.
 
 Thoughts?


What if it's an alias?  Return the alias identifier's name or the thing 
which it aliases?

Template parameters?  Return the name of the template parameter or the 
actual object passed in?

-- 
Regards,
James Dunne
Apr 02 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
kris wrote:

 I'll propose that a new property be added, somewhat like the .mangleof 
 property. Instead, a .nameof property would simply return the lexical 
 token for the named entity. Doesn't matter whether it refers to a 
 struct, class, some attribute thereof, enum types or members, whatever 
 ... the x.nameof should just return a char[] of the respective name.
 
 Thoughts?


This would be great.


Sean
Apr 02 2006
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <e0pqn7$1ngo$1 digitaldaemon.com>, kris says...

I'll propose that a new property be added, somewhat like the .mangleof 
property. Instead, a .nameof property would simply return the lexical 
token for the named entity. Doesn't matter whether it refers to a 
struct, class, some attribute thereof, enum types or members, whatever 
... the x.nameof should just return a char[] of the respective name.

Thoughts?


It gets my vote - but there are a few kinks to work out.

For instance, how does this compare to .classname or TypeInfo.toString()?

I'd imagine that it would follow the same behavior as .mangleof (possibly all
the way around), with respect to aliases and typedefs.  Templates might be kind
of sticky though -- any ideas on that?

- EricAnderton at yahoo
Apr 03 2006
parent reply kris <foo bar.com> writes:
pragma wrote:

 In article <e0pqn7$1ngo$1 digitaldaemon.com>, kris says...
 

I'll propose that a new property be added, somewhat like the .mangleof 
property. Instead, a .nameof property would simply return the lexical 
token for the named entity. Doesn't matter whether it refers to a 
struct, class, some attribute thereof, enum types or members, whatever 
... the x.nameof should just return a char[] of the respective name.

Thoughts?


 
 
 It gets my vote - but there are a few kinks to work out.
 
 For instance, how does this compare to .classname or TypeInfo.toString()?


For classes, I think it would be equivalent to .classname (since that 
returns a char[] of the class name). I suspect TypeInfo.toString() is a 
different kettle of fish, since it deals with type information instead 
of names per se?


 
 I'd imagine that it would follow the same behavior as .mangleof (possibly all
 the way around), with respect to aliases and typedefs.  Templates might be kind
 of sticky though -- any ideas on that?


I think it would, as you say, follow the same behaviour as .mangleof ~ a 
  simple concept with simple rules; Had imagined .nameof would simply 
give you an equivalent name for anything that you can legitimately 
dereference. Regarding templates, does .mangleof do anything unexpected?
Apr 03 2006
parent pragma <pragma_member pathlink.com> writes:
In article <e0rsbe$1hdm$1 digitaldaemon.com>, kris says...

pragma wrote:

 In article <e0pqn7$1ngo$1 digitaldaemon.com>, kris says...
 

I'll propose that a new property be added, somewhat like the .mangleof 
property. Instead, a .nameof property would simply return the lexical 
token for the named entity. Doesn't matter whether it refers to a 
struct, class, some attribute thereof, enum types or members, whatever 
... the x.nameof should just return a char[] of the respective name.

Thoughts?


 
 
 It gets my vote - but there are a few kinks to work out.
 
 For instance, how does this compare to .classname or TypeInfo.toString()?


For classes, I think it would be equivalent to .classname (since that 
returns a char[] of the class name). I suspect TypeInfo.toString() is a 
different kettle of fish, since it deals with type information instead 
of names per se?


 
 I'd imagine that it would follow the same behavior as .mangleof (possibly all
 the way around), with respect to aliases and typedefs.  Templates might be kind
 of sticky though -- any ideas on that?


I think it would, as you say, follow the same behaviour as .mangleof ~ a 
  simple concept with simple rules; Had imagined .nameof would simply 
give you an equivalent name for anything that you can legitimately 
dereference. Regarding templates, does .mangleof do anything unexpected?


Well, you can only name-mangle a template instance, since they technically don't
exist otherwise.  The result is often a *very* complicated mangling that is a
composite of the template name, namespace and all the type arguments that
comprise it.  So the .nameof might have to be something simple, and less useful
and unique than the .mangleof rendition.

class Foo(X){}
const char[] bar = Foo!(int).mangleof; // should probably just yield "Foo"

- EricAnderton at yahoo
Apr 03 2006
prev sibling parent reply Tom <ihate spam.com> writes:
This is something that has been discussed before. Don't know why it has 
been rejected though.

This feature I'd love to see implemented in D. All these kind of little 
details makes D very attractive for C/C++ programmers (some of them wish 
there was a prettier syntax for C++ and they see D as just that, in the 
beginning of course). Believe me I know people that loves this kind of 
stuff, though it would be just a little detail for some points of view, 
it's not just about saving a few lines of code, it's also about nicer 
and prettier code (avoids duplicating stuff).

Hope to hear the proposal again soon in the main newsgroup.

Regards,
--
Tom;

kris escribió:

 Ben Gardner wrote:

 I've done that "the hard way" in C.
 Here's an example in D:

 /////
 import std.stdio;
 import std.string;

 enum X {
   Apple,
   Bat,
   Car,
 }

 char [][] X_names = [
    X.Apple : "Apple",
    X.Bat   : "Bat",
    X.Car   : "Car",
 ];

 char [] get_X_name(X e)
 {
    if ((e >= X.min) && (cast(int)e < X_names.length) &&
        (X_names[e] !is null)) {
       return X_names[e];
    }
    return ("invalid");
 }

 X get_X_id(char [] name)
 {
    for (int idx = 0; idx < X_names.length; idx++) {
       if ((X_names[idx] !is null) && (icmp(X_names[idx], name) == 0))
          return cast(X)idx;
    }
    return cast(X)-1;
 }

 void main(char [][] args)
 {
    for (int i = -1; i < 4; i++)
    {
       writef("%d = '%s'\n", i, get_X_name(cast(X)i));
    }

    char [] name = "bat";
    writef("id for '%s' is %d\n", name, cast(int)get_X_id(name));
 }
 ////

 Running this produces the output:
 -1 = 'invalid'
 0 = 'Apple'
 1 = 'Bat'
 2 = 'Car'
 3 = 'invalid'
 id for 'bat' is 1

 Ben

 Hasan Aljudy wrote:


 say I have an enum

    enum X
    {
     A,
     B,
     C
    }

 and I have

    void someFunc( X e )
    {
     //.. some code
    }

 I want to print the value of 'e' but I don't want to get a number!! I
 want to get a string that represents it. i.e. A or B or C


    void someFunc( X e )
    {
       toString(e);
       e.string;
       e.value;
       //or something like that ..
    }

 Is there any such thing in D?




 
 
 I'll propose that a new property be added, somewhat like the .mangleof 
 property. Instead, a .nameof property would simply return the lexical 
 token for the named entity. Doesn't matter whether it refers to a 
 struct, class, some attribute thereof, enum types or members, whatever 
 ... the x.nameof should just return a char[] of the respective name.
 
 Thoughts?
Apr 03 2006
parent reply kris <foo bar.com> writes:
 Hope to hear the proposal again soon in the main newsgroup.


You mean, perhaps Walter does not read D.Learn as much as the other 
forums? Worth cross-posting, then, since there seems to be a general 
feeling of "worthiness" on this one ... (see the rest of the thread)



Tom wrote:

 This is something that has been discussed before. Don't know why it has 
 been rejected though.
 
 This feature I'd love to see implemented in D. All these kind of little 
 details makes D very attractive for C/C++ programmers (some of them wish 
 there was a prettier syntax for C++ and they see D as just that, in the 
 beginning of course). Believe me I know people that loves this kind of 
 stuff, though it would be just a little detail for some points of view, 
 it's not just about saving a few lines of code, it's also about nicer 
 and prettier code (avoids duplicating stuff).
 
 Hope to hear the proposal again soon in the main newsgroup.
 
 Regards,
 -- 
 Tom;
 
 kris escribió:
 

 Ben Gardner wrote:


 I've done that "the hard way" in C.
 Here's an example in D:

 /////
 import std.stdio;
 import std.string;

 enum X {
   Apple,
   Bat,
   Car,
 }

 char [][] X_names = [
    X.Apple : "Apple",
    X.Bat   : "Bat",
    X.Car   : "Car",
 ];

 char [] get_X_name(X e)
 {
    if ((e >= X.min) && (cast(int)e < X_names.length) &&
        (X_names[e] !is null)) {
       return X_names[e];
    }
    return ("invalid");
 }

 X get_X_id(char [] name)
 {
    for (int idx = 0; idx < X_names.length; idx++) {
       if ((X_names[idx] !is null) && (icmp(X_names[idx], name) == 0))
          return cast(X)idx;
    }
    return cast(X)-1;
 }

 void main(char [][] args)
 {
    for (int i = -1; i < 4; i++)
    {
       writef("%d = '%s'\n", i, get_X_name(cast(X)i));
    }

    char [] name = "bat";
    writef("id for '%s' is %d\n", name, cast(int)get_X_id(name));
 }
 ////

 Running this produces the output:
 -1 = 'invalid'
 0 = 'Apple'
 1 = 'Bat'
 2 = 'Car'
 3 = 'invalid'
 id for 'bat' is 1

 Ben

 Hasan Aljudy wrote:


 say I have an enum

    enum X
    {
     A,
     B,
     C
    }

 and I have

    void someFunc( X e )
    {
     //.. some code
    }

 I want to print the value of 'e' but I don't want to get a number!! I
 want to get a string that represents it. i.e. A or B or C


    void someFunc( X e )
    {
       toString(e);
       e.string;
       e.value;
       //or something like that ..
    }

 Is there any such thing in D?





 I'll propose that a new property be added, somewhat like the .mangleof 
 property. Instead, a .nameof property would simply return the lexical 
 token for the named entity. Doesn't matter whether it refers to a 
 struct, class, some attribute thereof, enum types or members, whatever 
 ... the x.nameof should just return a char[] of the respective name.

 Thoughts?
Apr 04 2006
next sibling parent reply Tom <ihate spam.com> writes:
kris escribió:

  > Hope to hear the proposal again soon in the main newsgroup.
 
 You mean, perhaps Walter does not read D.Learn as much as the other 
 forums? Worth cross-posting, then, since there seems to be a general 
 feeling of "worthiness" on this one ... (see the rest of the thread)


It's just that this kind of things must be heavily accepted in the main 
newsgroup before Walter takes it really on account. This is true at 
least with this kind of make-D-prettier proposals (It seems that way 
though I could be wrong).

Tom;


 
 
 Tom wrote:

 
 kris escribió:


 Ben Gardner wrote:






[snip]
Apr 04 2006
next sibling parent reply Justin C Calvarese <technocrat7 gmail.com> writes:
Tom wrote:

 kris escribió:

  > Hope to hear the proposal again soon in the main newsgroup.

 You mean, perhaps Walter does not read D.Learn as much as the other 
 forums? Worth cross-posting, then, since there seems to be a general 
 feeling of "worthiness" on this one ... (see the rest of the thread)


 
 It's just that this kind of things must be heavily accepted in the main 
 newsgroup before Walter takes it really on account. This is true at 
 least with this kind of make-D-prettier proposals (It seems that way 
 though I could be wrong).
 
 Tom;


As far as I can tell, many people are in favor of x.nameof (and I'm one 
of them). I haven't noticed that anyone is against this, but I think 
it's more important for Walter to stamp out the known bugs and establish 
D 1.0.

I'd be happy if x.nameof were part of D 1.1 though. ;)

-- 
jcc7
Apr 04 2006
parent reply "John C" <johnch_atms hotmail.com> writes:
"Justin C Calvarese" <technocrat7 gmail.com> wrote in message 
news:e0vepu$es1$1 digitaldaemon.com...

 Tom wrote:

 kris escribió:

  > Hope to hear the proposal again soon in the main newsgroup.

 You mean, perhaps Walter does not read D.Learn as much as the other 
 forums? Worth cross-posting, then, since there seems to be a general 
 feeling of "worthiness" on this one ... (see the rest of the thread)


 It's just that this kind of things must be heavily accepted in the main 
 newsgroup before Walter takes it really on account. This is true at least 
 with this kind of make-D-prettier proposals (It seems that way though I 
 could be wrong).

 Tom;


 As far as I can tell, many people are in favor of x.nameof (and I'm one of 
 them). I haven't noticed that anyone is against this, but I think it's 
 more important for Walter to stamp out the known bugs and establish D 1.0.

 I'd be happy if x.nameof were part of D 1.1 though. ;)

 -- 
 jcc7


I'd prefer TypeInfo to be extended instead and allow typeid to take an enum 
member.

    enum Colour {
        CADET_BLUE,
        GOLDENROD,
        SEA_SHELL
    } // Upper-case enum members are recommended in the spec.
    char[] colorName = typeid(Colour.SEA_SHELL).name; // produces 
"SEA_SHELL"

Now, because no one would want to expose a string like "SEA_SHELL" to users, 
we might need to extend enums to optionally allow a string representation of 
its members at declaration:

    enum Colour {
        CADET_BLUE : "CadetBlue",
        GOLDENROD : "Goldenrod",
        SEA_SHELL : "SeaShell"
    }

While we're on the subject of operators, I think they need to made more 
consistent so that they're all callable in the same fashion. At the moment, 
we've got something.sizeof and something.mangleof but typeof(something) and 
typeid(something). I don't care which we settle on, but we should settle on 
one (I've a slight preference for something.typeid).

John C.
Apr 05 2006
parent reply kris <foo bar.com> writes:
John C wrote:
[snip]

 
 I'd prefer TypeInfo to be extended instead and allow typeid to take an enum 
 member.
 
     enum Colour {
         CADET_BLUE,
         GOLDENROD,
         SEA_SHELL
     } // Upper-case enum members are recommended in the spec.
     char[] colorName = typeid(Colour.SEA_SHELL).name; // produces 
 "SEA_SHELL"


There's a potential problem there. TypeInfo is typically generated for 
each new type; not for each instance of a type. What you suggest would 
seem to require a specific TypeInfo for each instance rather than just 
for each type (to expose each instance name). That would be somewhat 
wasteful: wouldn't want that to happen for, say, every int variable that 
I wish to .nameof upon;

x.nameof does not have that issue at all.

Typeinfo also has a bit of a problem with verbosity: I currently have to 
opine "typeid(typeof(MyVarName))" to the compiler, just to get TypeInfo. 
This starts to look like C++ <g>

private static Attribute[] map =
[
{typeid(typeof(Tuple.label)),       Tuple.label.offsetof},
{typeid(typeof(Tuple.quantity)),    Tuple.quantity.offsetof},
{typeid(typeof(Tuple.description)), Tuple.description.offsetof},
];




 Now, because no one would want to expose a string like "SEA_SHELL" to users, 
 we might need to extend enums to optionally allow a string representation of 
 its members at declaration:
 
     enum Colour {
         CADET_BLUE : "CadetBlue",
         GOLDENROD : "Goldenrod",
         SEA_SHELL : "SeaShell"
     }


It could be said that complicates things for minimal gain? Why not just 
give them reasonable names to begin with?

enum Colour {CadetBlue, GoldenRod, SeaShell};

where Colour.CadetBlue.nameof == "CadetBlue"

BTW: it's a nice change to see the English spelling of Colour :)



 While we're on the subject of operators, I think they need to made more 
 consistent so that they're all callable in the same fashion. At the moment, 
 we've got something.sizeof and something.mangleof but typeof(something) and 
 typeid(something). I don't care which we settle on, but we should settle on 
 one (I've a slight preference for something.typeid).


Couldn't agree more. I much prefer the .property approach
Apr 05 2006
parent "John C" <johnch_atms hotmail.com> writes:
"kris" <foo bar.com> wrote in message 
news:e0vvs2$1b27$1 digitaldaemon.com...

 John C wrote:
 [snip]

 I'd prefer TypeInfo to be extended instead and allow typeid to take an 
 enum member.

     enum Colour {
         CADET_BLUE,
         GOLDENROD,
         SEA_SHELL
     } // Upper-case enum members are recommended in the spec.
     char[] colorName = typeid(Colour.SEA_SHELL).name; // produces 
 "SEA_SHELL"


 There's a potential problem there. TypeInfo is typically generated for 
 each new type; not for each instance of a type. What you suggest would 
 seem to require a specific TypeInfo for each instance rather than just for 
 each type (to expose each instance name). That would be somewhat wasteful: 
 wouldn't want that to happen for, say, every int variable that I wish to 
 .nameof upon;


This is true. I was trying (but failed - sigh) to make it consistent with 
how we already retrieve class names and such. I guess, without full 
introspective capacilities, D needs another way to get partial type 
information at low cost.


 x.nameof does not have that issue at all.

 Typeinfo also has a bit of a problem with verbosity: I currently have to 
 opine "typeid(typeof(MyVarName))" to the compiler, just to get TypeInfo. 
 This starts to look like C++ <g>

 private static Attribute[] map =
 [
 {typeid(typeof(Tuple.label)),       Tuple.label.offsetof},
 {typeid(typeof(Tuple.quantity)),    Tuple.quantity.offsetof},
 {typeid(typeof(Tuple.description)), Tuple.description.offsetof},
 ];




 Now, because no one would want to expose a string like "SEA_SHELL" to 
 users, we might need to extend enums to optionally allow a string 
 representation of its members at declaration:

     enum Colour {
         CADET_BLUE : "CadetBlue",
         GOLDENROD : "Goldenrod",
         SEA_SHELL : "SeaShell"
     }


 It could be said that complicates things for minimal gain? Why not just 
 give them reasonable names to begin with?

 enum Colour {CadetBlue, GoldenRod, SeaShell};

 where Colour.CadetBlue.nameof == "CadetBlue"


I must say, I never really liked the Java-style upper case naming convention 
which D seems to have adopted for enums. Pascal casing looks much better 
than HEY_IM_TALKING_TO_YOU.

Since providing a TypeInfo for everything would be wasteful, and at the risk 
of performing a complete about-face, let's have the following availble for 
everything:

.nameof
    Returns the unqualified name of a declared symbol, eg "EnumMember"
.fullnameof
    Returns the qualified name of a declared symbol, eg 
"module.Enum.EnumMember"


 BTW: it's a nice change to see the English spelling of Colour :)



 While we're on the subject of operators, I think they need to made more 
 consistent so that they're all callable in the same fashion. At the 
 moment, we've got something.sizeof and something.mangleof but 
 typeof(something) and typeid(something). I don't care which we settle on, 
 but we should settle on one (I've a slight preference for 
 something.typeid).


 Couldn't agree more. I much prefer the .property approach
Apr 05 2006
prev sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Tom wrote:

 kris escribió:

  > Hope to hear the proposal again soon in the main newsgroup.

 You mean, perhaps Walter does not read D.Learn as much as the other 
 forums? Worth cross-posting, then, since there seems to be a general 
 feeling of "worthiness" on this one ... (see the rest of the thread)


 
 It's just that this kind of things must be heavily accepted in the main 
 newsgroup before Walter takes it really on account. This is true at 
 least with this kind of make-D-prettier proposals (It seems that way 
 though I could be wrong).
 
 Tom;
 

 Tom wrote:

 kris escribió:


 Ben Gardner wrote:






 [snip]


I don't even read D.learn, and I imagine that is the case of a lot of others as
well.
Apr 04 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
 I'll propose that a new property be added, somewhat like the 
 .mangleof property. Instead, a .nameof property would simply return 
 the lexical token for the named entity. Doesn't matter whether it 
 refers to a struct, class, some attribute thereof, enum types or 
 members, whatever ... the x.nameof should just return a char[] of the 
 respective name.






I would love to have something which could convert enum values to 
strings; but I think there are some interesting possibilities to consider.

An approximation to .nameof can already be synthesised using template 
tricks with .mangleof. It does not, however, work for enum values, and 
doesn't really work for local variables (because local symbol names 
can't be alias parameters -- except for mixins).

One issue that I can see with this proposal is, what name should be 
returned? My template implementation provides symbolnameof, 
qualifiednameof, prettynameof, and manglednameof.

It also allows you to get the original name from an alias template 
parameter, allowing something like:

template debugPrint (alias a) {
void debugPrint()
{
    writefln("The value of ", qualifiednameof!(a), " is ", a);
}

only works as a mixin unfortunately. Usage:

void func()
{
   int x = 7;
   mixin debugPrint!(x);
   debugPrint();
}

// output:
The value of test.func.x is 7

------------
Obviously much too ugly to be much use right now, but I think there are 
some tantalising possibilities there, which should be considered in a 
nameof proposal.
Apr 05 2006
parent kris <foo bar.com> writes:
Don Clugston wrote:

 

 I'll propose that a new property be added, somewhat like the 
 .mangleof property. Instead, a .nameof property would simply return 
 the lexical token for the named entity. Doesn't matter whether it 
 refers to a struct, class, some attribute thereof, enum types or 
 members, whatever ... the x.nameof should just return a char[] of 
 the respective name.






 
 
 I would love to have something which could convert enum values to 
 strings; but I think there are some interesting possibilities to consider.
 
 An approximation to .nameof can already be synthesised using template 
 tricks with .mangleof. It does not, however, work for enum values, and 
 doesn't really work for local variables (because local symbol names 
 can't be alias parameters -- except for mixins).
 
 One issue that I can see with this proposal is, what name should be 
 returned? My template implementation provides symbolnameof, 
 qualifiednameof, prettynameof, and manglednameof.
 
 It also allows you to get the original name from an alias template 
 parameter, allowing something like:
 
 template debugPrint (alias a) {
 void debugPrint()
 {
    writefln("The value of ", qualifiednameof!(a), " is ", a);
 }
 
 only works as a mixin unfortunately. Usage:
 
 void func()
 {
   int x = 7;
   mixin debugPrint!(x);
   debugPrint();
 }
 
 // output:
 The value of test.func.x is 7
 
 ------------
 Obviously much too ugly to be much use right now, but I think there are 
 some tantalising possibilities there, which should be considered in a 
 nameof proposal.


Was kinda' hoping you'd have a go at this;

I'd expected x.nameof to return an unqualified name (what you called the 
symbol name?). The reasoning was twofold: it should be very easy to 
implement consistently, and one could perhaps construct a 
fully-qualified name by concatenation (via ~) of component symbols? The 
compiler would probably fold them, since each would be the equivalent of 
a const char[]? Or, maybe an x.fullnameof might appear later? Anyway, 
the goal was to expose something simple to implement and easy to use. As 
usual, you've opened up a whole bunch of other useful possibilities <g>
Apr 05 2006