Getting the string representing the enum value ~ Proposal

kris foo at bar.com
Wed Apr 5 01:41:38 PDT 2006


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



More information about the Digitalmars-d-learn mailing list