Re: Re: Let's discuss enums!

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).