Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88420
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.176 as permitted sender)
To: Stig Bakken <stig@stigbakken.com>, Rowan Collins <rowan.collins@gmail.com>
References: <55FB4791.4040807@gmail.com> <55FB4DFC.2060204@domain.invalid>
 <55FB555C.9070701@gmail.com>
 <CABM2syufBo6DN9gzVQ_QL-ynty19AKEWe7J1RFKA6iNjX1SJ-A@mail.gmail.com>
Cc: internals@lists.php.net
Message-ID: <5601ABED.2080902@gmail.com>
Date: Tue, 22 Sep 2015 15:28:45 -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: <CABM2syufBo6DN9gzVQ_QL-ynty19AKEWe7J1RFKA6iNjX1SJ-A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Let's discuss enums!
From: jgmdev@gmail.com (Jefferson Gonzalez)

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).