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
It's a pretty big new concept that would need to be introduced if this
was desired: extension methods.
I think it's overkill myself. Something like this is fine:
class Grade {
enum {
A_PLUS,
A,
B_PLUS,
B,
...,
FAIL,
NOT_AVAILABLE,
}
public static function passing($grade) {
return $grade>=self::D;
}
}
$grade=Grade::B;
echo Grade::passing($grade)?"passing":"not passing";
Having extension methods would also make enums much less efficient, as
they would have to be stored as objects so their exact enum type could
be determined at runtime if calling a method.
I guess supporting type hinting properly also requires this, if that's
desired, though. But I personally think something simple, much closer to
the existing RFC, is fine. There isn't much benefit in type hinting--it
could catch some programmer errors, but that's it--a small debugging
tool. If it doesn't actually enable overloading (in the C++ sense) or
something like that, it's not really an advantage.
Regarding named enums, this could just be a shortcut for an enum in a
class:
enum Grade {
A_PLUS,
A,
...
}
is shorthand for
class Grade {
enum {
A_PLUS,
A,
...
}
}
so you then do Grade::A etc.. You could disallow named enums in classes,
or they could be named purely to make code self-documenting.
Enum type in the database is totally different because it's a
constraint, not an alias to some underlying piece of data like enums
in many programming languages. I think enforcing such constraint in
PHP would be quite complicated.
No, I think enums in MySQL at least are true types, not just
constraints--they are internally stored as integers and various
optimisations are done with queries based on this.
I agree strings as values do have the advantage of more robust (albeit
less efficient) serialisation, including interacting with databases such
as MySQL with enum types. So I think this would be worth allowing, but
no more.
So I would suggest having enum value allocation work like array indexes.
If you don't supply a value, it uses the next unused integer. But you
may alternatively supply an integer or a string. So, doing
enum {
FIRST,
SECOND,
THIRD,
LAST = 'last'
}
would be much like doing
$enum[]='FIRST';
$enum[]='SECOND';
$enum[]='THIRD';
$enum['last']='LAST';
in that 0, 1, 2 and 'last' are used.
There's a few more cents from me. :-)
Ben.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
