Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112636
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <5120eee2-56c4-4608-9e41-4dd05563fef7@www.fastmail.com>
In-Reply-To: <67c9d05a-f0a7-fcea-32ea-7a4e409308a1@mabe.berlin>
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com>
 <67c9d05a-f0a7-fcea-32ea-7a4e409308a1@mabe.berlin>
Date: Tue, 29 Dec 2020 09:42:04 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Dec 29, 2020, at 2:48 AM, Marc wrote:
> 
> On 28.12.20 21:21, Larry Garfield wrote:
> > Hello, Internalians!
> >
> > After considerable discussion and effort, Ilija and I are ready to offer you round 2 on enumerations.  This is in the spirit of the previous discussion, but based on that discussion a great deal has been reworked.  The main change is that Enumeration Cases are now object instances of the Enumeration class rather than their own class.  Most of the other changes are knock-on effects of that.
> >
> > Of particular note:
> >
> > * Cases may not have methods or constants on them.  They're just dumb values.
> > * Enums themselves may have methods, static methods, or constants.
> > * Traits are supported, as long as they don't have properties.
> > * The value() method on scalar enums is now a property.
> >
> > The full RFC is here, and I recommend reading it again in full given how much was updated.
> 
> I did and the RFC looks really awesome :+1:
> 
> I don't have time to test the implementation but I noticed one thing:
> 
> > If the enumeration is not a Scalar Enum, the array will be packed
> (indexed sequentially starting from 0). If the enumeration is a Scalar
> Enum, the keys will be the corresponding scalar for each enumeration.
> 
> I don't think using the scalar values as keys is a good idea. What
> happens if we want to support scalar float values? (Why are they
> actually not supported in the first place?)

That's why floats are not supported, in fact, because what happens to them when they are made into an array key is non-obvious.  (PHP would say to convert to a string, but that's always fussy with possible data loss in some cases, etc.)  We decided to just avoid that problem until/unless someone found a good use case for float enums.  No all languages support them as is, so there is precedent.

> Also I think it's more natural if both enum types return a
> zero-indexed-array of cases.

The goal is to make it easy to work with them, and having a clean lookup map readily available is very convenient.  If you don't care about the scalar equivalent then you can safely ignore them.  If you do want them, then you have a lookup table ready-made for you.  That's the logic we were working from.

--Larry Garfield