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