Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
To: Jefferson Gonzalez <jgmdev@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>
Cc: internals@lists.php.net
Message-ID: <5602ED20.1040402@gmail.com>
Date: Wed, 23 Sep 2015 19:19:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <5601ABED.2080902@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: rowan.collins@gmail.com (Rowan Collins)

Jefferson Gonzalez wrote on 22/09/2015 20:28:
> 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.

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.

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.

Every other action I can think of is either the same, slower, or 
impossible if you use an int-based representation:

- Comparing two enum instances can again be optimised based on the "only 
one instance" rule: you can directly compare the pointers.
- 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.
- 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.

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.

Regards,
-- 
Rowan Collins
[IMSoP]