Re: [PHP-DEV] Re: Clarification on the Enum language structure

[Ben Schmidt]

On 19/02/11 5:37 AM, Martin Scotta wrote:
Enums are a new "type", they are different to any existent type.(if not,
what is the point of creating them)

It seems to me, however, that what you are suggesting makes them almost the same 
as classes, and I don't really think there is any point in doing that.

To me, enumerations should be lightweight and efficient, closer to defining 
constants than defining classes.

Ben.



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




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php