Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88316
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
To: Jefferson Gonzalez <jgmdev@gmail.com>, internals@lists.php.net
References: <55FB4791.4040807@gmail.com> <55FB4DFC.2060204@domain.invalid>
 <55FB555C.9070701@gmail.com> <55FB7505.6000604@gmail.com>
Message-ID: <55FBE306.3090204@gmail.com>
Date: Fri, 18 Sep 2015 11:10:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55FB7505.6000604@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Let's discuss enums!
From: rowan.collins@gmail.com (Rowan Collins)

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]