Getting the string representing the enum value ~ Proposal

[John C]

"kris" <foo at bar.com> wrote in message 
news:e0vvs2$1b27$1 at 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