On 09/22/2015 06:38 AM, Stig Bakken wrote:
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
Is also worth noting that if you keep performance in mind, enums whith
values represented as integers should be a much more
performant/efficient implementation since it would require less cpu
cycles and memory to build and read them. In the other side the RFC
proposal is treating the enum values as objects which would require a
bigger zval and more cpu cycles to construct them and read them.
So basically from a performance perspective enums expressed as:
class enum {
const FIELD1=0;
const FIELD2=1;
}
should go more easy on the engine than:
class enum extends enumeration
{
public FIELD1 = new enum(value, name);
public FIELD2 = new enum(value, name);
...
}
The latter would be bloated, which emulates the java way of doing
things, one of the reasons why JVM consumes so much ram and cpu cycles
for simple applications.
Again, enumerations should be a nice way of grouping/categorizing
values/flags for a specific use. Over-engineering the concept can lead
to bloatness.
Enums should offer the commodities that we don't have with:
class MyConstants{
const SOME_CONST;
const OTHER_CONST;
}
These should be:
1. dedicated syntax
2. type hinting with range checking
3. much better and concise documentation that clearly shows what type of
constants/flags a parameter can receive
Everything else besides that can be considered over-engineering and
bloatness (I over used the 'bloatness' term :D).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
