Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88450
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.177 as permitted sender)
To: Rowan Collins <rowan.collins@gmail.com>, Stig Bakken <stig@stigbakken.com>
References: <55FB4791.4040807@gmail.com> <55FB4DFC.2060204@domain.invalid>
 <55FB555C.9070701@gmail.com>
 <CABM2syufBo6DN9gzVQ_QL-ynty19AKEWe7J1RFKA6iNjX1SJ-A@mail.gmail.com>
 <5601ABED.2080902@gmail.com> <5602ED20.1040402@gmail.com>
Cc: internals@lists.php.net
Message-ID: <560301FA.3000105@gmail.com>
Date: Wed, 23 Sep 2015 15:48:10 -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: <5602ED20.1040402@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/23/2015 02:19 PM, Rowan Collins wrote:
> The internal implementation can never be quite as simple as an IS_LONG
> zval if we want to provide anything at all beyond a C-style enum. I for
> one do not want Days::MONDAY === Months::JANUARY to return true, and nor
> should typeof(Days::MONDAY) return "long"; this requires at the very
> least a struct with type name (enum "class") and value.

Right, if we think of the implementation as a class with constant 
properties, then the Days enum would hold an array/hash of associative 
zvals, the zvals structure should include a pointer to a 
zend_enum_struct, this zend_enum_struct may hold a pointer to the parent 
zend_class_entry/zend_enum_entry, a pointer to its name as stored on the 
zend_class_entry/zend_enum_entry properties table, and the 
ordinal/numerical value. So:

function something(Days $day);
something(Days::Monday);

would be a matter of comparing the zend_class_entry/zend_enum_entry 
pointer referenced on Monday with that of the Days enum.

Again comparing Days::MONDAY === Months::JANUARY should be fast if we 
only compare the pointer of the zend_enum_entry.

> Memory efficiency is only trivially different, since all possible
> instances exist in memory only once, so each zval pointing at
> Days::MONDAY would just be a single pointer to the single instance of
> that structure. Initial creation of the enum instances would be slower,
> but again only needs to happen once when the enum is declared, so is
> unlikely to be a major concern.

Initializing a zend_enum_struct that only holds a pointer to parent 
enum, pointer to name, and ordinal value would be faster and require 
less memory than initializing a new class for each enum value. It is 
true that this only happens once but every bit counts for better 
performance. After all php model for every request is Execute/Die, 
Execute/Die... it doesn't keeps everything initialized and ready for use.

> - Getting the name of a class constant based on its definition (e.g. to
> display an Exception's code in human-readable form) requires extremely
> inefficient use of reflection. An int-based enum implementation would
> have to do something similar, an object-based one could cache the
> information in the instance.

As I said before, if we store a pointer to the property name of the 
zend_class_entry/zend_enum_entry directly on the zend_enum_struct we can 
retrieve its name rapidly without going into the 
zend_class_entry/zend_enum_entry and doing a properties lookup.

> - Absolutely any other additional behaviour or fields would be either
> impossible with an int-based representation, or require exactly the same
> lookups as an object-based implementation would provide anyway.

Any other fancy stuff like Days::Monday->Something() would be in my 
opinion over engineering the typical use of enumerations.

> Looking at Levi's PoC branch, the actual approach taken is a hybrid
> anyway: the _zend_enum struct directly holds the name and an "ordinal"
> z_long directly, and only access the object representation if these two
> pieces of information are not sufficient.

Nice that theres already work on some implementation :), I have missed 
this feature so much on PHP.