On Fri, Sep 18, 2015 at 2:05 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > 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.
Actually, you need to think about compatibility in a bigger perspective. One of the first things I would want do if PHP were to grow enums, is to add support for it to Apache Thrift. For those not familiar with it, Thrift is basically an IDL for specifying messages and services (APIs) that generates code for a lot of languages, including PHP. Same principle as Google's Protocol Buffers / grpc. Anyway, some of the point in using an IDL for your APIs is having a graceful way to deal with changes over time, because you must always deal with a certain amount of old clients or servers. Thrift and Protobuf's enums are represented as integers internally, and that is what goes on the wire. If you change the name of an enum field in your IDL, you will get a source incompatibility, but that's acceptable as long as you change the code. It only affects that single client or server. What is not okay is to change the enum's integer representation, because that breaks the protocol, and you can no longer communicate with older clients or servers. The point I'm trying to make is that an enum's normalized representation should be an integer, and that is also how it should be serialized. It also happens to be how most other languages chose to represent enums, and deviating from that will cause all kinds of pain the minute you need to do type conversions between formats or languages. - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
