Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88300
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
To: user@domain.invalid, internals@lists.php.net
References: <55FB4791.4040807@gmail.com> <55FB4DFC.2060204@domain.invalid>
Message-ID: <55FB555C.9070701@gmail.com>
Date: Fri, 18 Sep 2015 01:05:48 +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: <55FB4DFC.2060204@domain.invalid>
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)

On 18/09/2015 00:34, user@domain.invalid wrote:
> 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.

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?

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,

-- 
Rowan Collins
[IMSoP]