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.




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

Reply via email to