Enums are a new "type", they are different to any existent type.(if not,
what is the point of creating them)
Everybody agree that an enum is a set, in the mathematically point of view,
of names and values.
What we are discussing here is what should be those "values".
IMO that should be a programmer decision. Someone may like strings, other
integer.
Pragramers may want a simple enum... a couple of ordered elements, the
element itself is the value.
enum Letters {
A, B, C, [...], Z;
}
$a = Letters::A;
echo $a; // it would be nice to echo 'A'
but there are other situation where is not enough with the name, where you
need "values"
enum Numbers {
ONE(1), TWO(2), THREE(3), [...], NINE(9);
private $value;
function __construct($value) {
$this->value = $value;
}
function valueOf() {
return $this->value;
}
static function getNumber($value) {
switch( $number ) {
case 1: return self::ONE;
case 2: return self::TWO;
[...]
case 9: return self::NINE;
}
}
}
$num = Numbers::ONE;
var_dump( $num ); // enum (Numbers::ONE) ???
var_dump( $num->valueOf() ); // integer (1)
$four = Numbers::getNumber( 4 );
And note this has the same limitations that today's define:
enum BadEnum {
A( func() ), // error
B( $obj->meth() ), // error
C( new Object ); // error
}
And the enum implementation could provide some helpful methods out the box,
like __toString, or fromString
enum MySqlEnum {
A_CONSTANT, ANOTHER_ONE;
}
$foo = MySqlEnum::A_CONSTANT;
var_dump( (string) $foo ); // string "A_CONSTANT"
var_dump( MySqlEnum::ANOTHER_ONE === MySqlEnum::fromString('ANOTHER_ONE'));
MySqlEnum::getIterator(); // to iterate over the enum elements
Martin Scotta
On Fri, Feb 18, 2011 at 1:19 PM, Hannes Landeholm <landeh...@gmail.com>wrote:
> Let me jump in here and say that I agree that strings are useful. IMO
> any scalar type should be allowed for enum's. String enum's are great
> for understanding debug data. Also it would integrate smoothly with
> MySQL enums (building queries) and when you want to model enumerations
> in an external API or framework. When you say "enums should be
> integers" you assume that the programmer has the final decision on the
> values. But if you want to enumerate possible string return codes from
> an external API you'd be forced to write a translation function that
> translate the values you read to the internal enumeration
> representation.
>
> For example, say that http://www.example.org/api can return either
> "fail", "success" or "timeout", you'd like to put these in an
> enumeration so they make sense instead of having magic values
> scattered across the code.
>
> enum ExampleReturnCodes {
> FAILURE = "fail";
> SUCCESS = "success";
> TIMEOUT = "timeout";
> }
>
> if ($ret == ExampleReturnCodes::FAILURE)
> echo "noes";
>
> This also highlights why it would be nice to name enumerations just
> like classes. They provide a handle for the constants within so they
> can be used for reflection. See, I'd like to do something like:
>
> if ($ret enumof ExampleReturnCodes)
> \trigger_error("Unknown enumeration value returned!", \E_USER_ERROR);
>
> and:
>
> print("Got: " . ExampleReturnCodes::getName($ret)); // PrintsGot: FAILURE
>
> I'm suggesting this as an additional behavior. Declaring enumerations
> without names should make the contents be declared just as normal
> namespace/class constants. In addition, declaring a named enumeration
> "enum_name" in a class could give the enumeration the name either
> "enum_name" (if it wouldn't be confusing and the named collision risk
> is acceptable), "class_name::enum_name" (if the :: operator could be
> programmed to also resolved enumeration types and not only class
> constants), "class_name_enum_name" (if it would be acceptable to
> automatically merge the class name with the enumeration name) (and
> possibly other solutions). Another solution is to forbid class
> enumerations from being named and only use them as a constant grouping
> syntax.
>
> My 5 cents.
>
> Hannes
>
> On 18 February 2011 15:44, Arvids Godjuks <arvids.godj...@gmail.com>
> wrote:
> > 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
> >
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
