Jefferson Gonzalez wrote on 18/09/2015 03:20:
On 09/17/2015 08:05 PM, Rowan Collins wrote:
I don't think serializing to a name is particularly more inefficient
than serializing to an integer - depending on the internal
implementation, of course. Or do you mean efficiency in terms of the
length of the string produced?
Exactly! Lets say you want to create a MembershipStatus
enum MembershipStatus{
INACTIVE=0,
ACTIVE=1
}
It would be more memory/space efficient to store 1 or 0 in a database
or serialized string, also it would be faster to parse than storing
the full name, eg (bad serialized example but just to show the idea):
e:16:"MembershipStatus":1:{i:0;}
instead of
e:16:"MembershipStatus":1:{s:8:"INACTIVE";}
I would expect it to look more like this:
e:16:"MembershipStatus":8:"INACTIVE"
It seems to me that there are lots of things you could do to be
efficient - declared object properties could be serialized by their
ordinal position, rather than listing their names, for instance - but
that would make the serialization more fragile. It seems to me that
serializing enum values by order or "value" rather than name is much the
same thing.
The renaming thingy, I'm wouldn't be so sure because IDE's can
introduce refactoring tools for enumerations that rename all
occurrences of an enum to another. Unless you are working on a public
framework that many different people is using, in that case you would
restraint from renaming the enumerations.
Sure, but it seems more likely that somebody would add an extra value to
an enum in alphabetical order, thus messing up serialized ordinals, than
they are to refactor their code base to change the name of one of the
values.
And if you rename a class or property, serialized objects of that class
will already break, so having serialized enums break on the same action
seems perfectly natural, whereas having them silently unserialize to the
wrong value because you changed the ordinal positions of the values
seems rather dangerous.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
