Re: [RFC] Enumerations, Round 2
| From: | Larry Garfield | Date: | Tue, 29 Dec 2020 15:42:04 +0000 |
| Subject: | Re: [RFC] Enumerations, Round 2 | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112636@lists.php.net to get a copy of this message | ||
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