Newsgroups: php.internals,php.internals Path: news.php.net Xref: news.php.net php.internals:88310 php.internals:88311 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2716 invoked from network); 18 Sep 2015 02:21:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Sep 2015 02:21:01 -0000 X-Host-Fingerprint: 24.41.170.168 unknown Received: from [24.41.170.168] ([24.41.170.168:7465] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A6/53-19961-C057BF55 for ; Thu, 17 Sep 2015 22:21:00 -0400 To: internals@lists.php.net,Rowan Collins , internals@lists.php.net References: <55FB4791.4040807@gmail.com> <55FB4DFC.2060204@domain.invalid> <55FB555C.9070701@gmail.com> Message-ID: <55FB7505.6000604@gmail.com> Date: Thu, 17 Sep 2015 22:20:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FB555C.9070701@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 24.41.170.168 Subject: Re: Let's discuss enums! From: jgmdev@gmail.com (Jefferson Gonzalez) 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";} > Nor do I see it as particularly likely that somebody will rename an enum > member - that would instantly break all code referring to it anyway. > They could however change the order of fields without realising that it > would make any difference, since most access would be of the form > TypeName::ValueName. > > Regards, > 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.