> On Sep 17, 2015, at 20:15, Bob Weinand <bobw...@hotmail.com> wrote:
>
>> Am 18.09.2015 um 01:56 schrieb Rowan Collins <rowan.coll...@gmail.com>:
>>
>> On 18/09/2015 00:16, Marcio Almada wrote:
>>> A kitten is working on thathttps://wiki.php.net/rfc/enum. Many points
>>> on the linked RFC are compatible to the points you raised so it might
>>> be worth reading before even starting any new proposal.
>>
>> Aha, I hadn't seen that, should have thought to search the wiki. Still,
>> interesting that we seems to mostly agree on the key decisions, although
>> I've gone into more detail about things that he's left as Future Scope,
>> which is fair enough.
>>
>> The main thing I'd change if I was writing it is the implicit "ordinal"
>> property; I don't really see the point of insisting that the order I write
>> "Red, Green, Blue" has some meaning. On the other hand, I'd give much more
>> prominence to the name, e.g. by making values() return an associative array.
>> You're much more likely to want to say "the value whose name is 'RED'" than
>> "the value I defined first in the list", IMHO.
>>
>> If you have some kind of initialiser syntax for the values - with or without
>> a constructor - you get to have ordinals or explicit values (like the Flags
>> example) if you want them, and just names if not:
>>
>> enum RenewalAction{
>> Deny( 0 ),
>> Approve( 1 );
>>
>> public $ordinal;
>> }
>> enum Flags{
>> a (1 << 0),
>> b( 1 << 1),
>> c( 1 << 2),
>> d( 1 << 3 ); public $value; }
>>
>> enum PimaryColours { RED, GREEN, BLUE }
>>
>> Regards,
>>
>> --
>> Rowan Collins
>> [IMSoP]
>
> The reason it is not an associative array is that the names are not important.
>
> But we actually need ordinal(), else we'll end up writing
> array_search(TheEnum::values(), $value).
> It's mainly important for the purpose of serializing/unserializing (manually
> or internally).
>
> You never should *rely* on the ordinal value of the enum for anything. Enums
> are supposed to be value-less. It's a type. It's not a value. The only usage
> of the value is going external.
>
> Also, I honestly think the Flags example is a bad one. (At least as long as
> we don't have a possibility to typehint combined enums...). If you need that,
> use class constants. They provide exactly what you need.
>
> Bob
Besides providing serialization mapping (or, the equivalent of a __toString()
value if the enum is used in a strong context), an important benefit to
providing a value for enums would be to allow for changing or deprecating
enums. So you might want to say something like:
enum FormEvents {
PRE_SUBMIT,
PRE_BIND = PRE_SUBMIT, //deprecated name, provide mapping to new name
}
Another good reason for wanting to provide values is so that you could write
code like this:
$eventHandlers = [
FormEvents::PRE_SUBMIT => function() { … },
FormEvents::POST_SUBMIT => function() { … },
...
];
Although maybe the ideal solution here would be to allow for array indexes to
have more types than just int and string (so that the array index actually is
the enum, not some serialized representation).
-John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
