Just a couple of quick notes...
I think that your proposal looks good, but I'd like to suggest a few
> changes. First of all, I'd like to see the association with integers
> removed. An enum instance shouldn't just be a name for an integer, it
> should be more like a singleton instance of a special kind of class
> that can only ever have a predefined set of named instances. There
> should be no value associated with it.
Strongly disagree.
Enum-values absolutely must translate to a scalar value, probably an int -
otherwise, how would you map an enum to a database, or submit it's value
via a form?
Secondly, there already exists the capacity for arbitrary classes to
> be used in foreach and count you just have to implement Iterator and
> Countable. Other interfaces that all enums might want to implement
> automatically are ArrayAccess and Serializable. This would just
> require the enum itself to be an object (maybe of type enum or
> something) such that it can implement the relevant methods.
Strongly agree!
I'm not sure what would be the value of a dedicated enum in PHP - I think
enum as a base-class with special capabilities would be a much better idea.
The requirements for enumerators often grow as you work through a problem -
today, you just need a few scalar values, tomorrow you need to iterate over
the possible value, next week you find you need to filter the values based
on a set of criteria, the week after that you suddenly need a drop-down in
a user-interface and you discover each value needs a user-friendly
description in english, and so on and so forth...
If all you really need is a simple "indicator" value of some sort, just use
class-constants with integer values - works nicely.
If you need anything more than that, it's likely you'll soon need more than
an enum anyway, regardless of how "fancy" your enum implementation is. I
would also point out, that the more "advanced" features you add to your
enum, the more you will find those features resemble class-features.
Another point I'd make, is that for anything enum-related, you often end up
needing functions that translate, sort, or filter, based on the values of
that specific type - with a dedicated enum-type, you'll end up needing a
class to go along with your enum to handle those things. Why not just use a
class in the first-place then?
In strongly-typed, compiled languages, I see the case for enums.
For a language like PHP, I think classes and objects would make more sense.
As said, I tend towards class-constants myself, but let's take this:
enum Foo
{
Bar = 1,
Baz = 2
}
And compare to this:
class Foo extends Enum
{
public static $Bar;
public static $Baz;
}
Foo::$Bar = new Foo(1);
Foo::$Baz = new Foo(2);
Was it really that much more work? How many enums do you add in a day? :-)
Now you can strongly type function-parameters, e.g.:
function doStuff(Foo $kind) { ... }
doStuff(Foo::$Bar);
doStuff(Foo::$Baz);
In a sense, enums in most languages are just crippled classes, although in
system-languages of course there's the benefit of enums performing better.
But I think you won't get a significant performance advantage from native
enums in a language like PHP.
Note that I'm assuming here that there's a base-class called Enum - it
would be nice if this implemented Iterator or IteratorAggregate, Countable,
etc.
The beauty of this approach as opposed to a native enum, is that you can
extend the Enum type to provide display-friendly values, ORM integration,
form integration, filtering, sorting, etc.
If you don't need any of those features, just use class constants.
Just my two cents...
