On 09/17/2015 07:06 PM, Rowan Collins wrote:
3) there should be no accessible "value" for a member; the value of
Weekdays::SUNDAY is simply Weekdays::SUNDAY, not 0 or 7 or 'SUNDAY' (I'm
thinking that internally, each member would be represented as an object
pointer, so there's no real benefit to forcing people to number
everything like some languages do)
Well, how are you supposed to serialize an enum value without some sort
of numerical representation or value? Maybe you could serialize it by
converting the enum to a string representation of its name but that
wouldn't be efficient and also if a developer refactored its code base
and renamed an enum, when unserializing the data it wouldn't be properly
assigned. Also other languages don't force you to assign value for an
enum constants, if I recall correctly languages like C/C++ automatically
assing an interger value to enumerations in they order they were typed so:
enum BadDays {MONDAY, SUNDAY, THURSDAY=5, SATURDAY}
would be MONDAY = 0, SUNDAY = 1, THURSDAY=5, SATURDAY=6
So assigning a value is optional.
I see the enum's rfc mentions boxing primitive types but that seems to
not solve what I'm saying here at all.
Enums should be a nice way of grouping constant values without hitting
on the performance (for everything else use a class). The rfc is
proposing a nice syntax but it doesn't fully covers
serialization/unserialization of enumerations.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
