Hello! I should comment on why people want strings as enum values - just look at ENUM type in MySQL. People use it, and if you take a look from that perspective - it makes sense.
But we are not a MySQL only world, so it does not make sense to do strings, because in other databases usually 1 byte integers are used for that. P.S. But I really like MySQL ENUM, it's really helpfull to see some meaningfull representation instead of plain numbers. And MySQL is able to convert enum to real integer like it is stored internaly: SELECT enum + 0 AS enum FROM table. Will get you the numbers, not the string representations. So it's really no brainer to make enumerations to work transparently with MySQL. 2011/2/18 Jarrod Nettles <jnett...@inccrra.org>: > I did some research on methods in enums and discovered that there is some > usefulness to the idea - I wouldn't go so far as to say that they would be > needed, but C#, for example, allows you to create extension methods for enums > and MSDN has a decent real-world example of its use. > > http://msdn.microsoft.com/en-us/library/bb383974.aspx > > I still don't understand why we would need string values (or any other > non-integral type) but like you said Ben - if you need something like that > you're not using the right datatype. Build a class. Here's my reasoning for > enum values. > > enum Wood{ > OAK, > ASH, > WILLOW, > GOPHER > } > > There's nothing in there that would necessitate needing a string value and > really, if you need a string value, pass in a string as your parameter! > Enumerations should be used to represent a set of data where the value itself > isn't so important, it’s the consistency of the value that's important. It’s > the fact that I've chosen gopher wood and I know that even though > Wood::GOPHER really means "3", I don't have to remember what "3" represents > because I can specifically type that I want gopher. > > > -----Original Message----- > From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au] > Sent: Thursday, February 17, 2011 4:52 PM > To: Martin Scotta > Cc: Jarrod Nettles; Thomas Gutbier; internals@lists.php.net > Subject: Re: [PHP-DEV] Re: Clarification on the Enum language structure > >>> Also, I feel like it should be restricted to integral types only, and >>> defaults to a zero-based incrementing integer. This is more in line with >>> other programming languages that already implement enums and will present >>> "expected behavior" for people moving over to PHP. >>> >> for me that's a plain old interpretation of constants. >> constant values were only integer values because of their implementation, >> nowadays they could be anything you want, int, float, string and even >> objects. > > I partially agree with that. > > I'm going to be a bit extreme here, but here's a thought: > > An enum is something you use conceptually for a set of constant values > which aren't related in a numerical or other fashion (where another type > would make more sense). In an enum, the only meaning of a constant is > the meaning expressed in that constant's name. > > So you shouldn't want to use ints, floats, strings, certainly not > objects, for enum values. If you feel yourself wanting to do this, an > enum is not the right datatype for your purpose--you should be using one > of those other types instead, possibly with a very few defined constants > for commonly-used or 'magic' values. > > The issue, then, of what type underlies an enum is mostly to do with > internal implementation, and more importantly, serialisation. Integers > are the simplest and most obvious way to do this. But short strings, > particularly string representations of the enum's symbols, could be a > nice way to make serialised data more readable, and less fragile (e.g. > if values are added to the enum, the mapping of strings to previous > constants does not change, no matter where the new value is added). > > I see no reason to use floats or objects (or resources, or arrays, or > ...). > > Ben. > > > > <html> > <body> > Jarrod Nettles Application Developer - Technology INCCRRA p 309.829.5327 - f > 309.828.1808 This e-mail message may contain privileged or confidential > information. If you are not the intended recipient, you may not disclose, > use, disseminate, distribute, copy > or rely upon this message or attachment in any way. If you received this > e-mail message in error, please return by forwarding the message and its > attachments to the sender. INCCRRA does not accept liability for any errors, > omissions, corruption or virus in > the contents of this message or any attachments that arises as a result of > e-mail transmission. Please consider your environmental responsibility before > printing this e-mail > </body> > </html> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
