Re: [RFC] Enumerations, Round 2
| From: | Marc | Date: | Tue, 29 Dec 2020 08:48:57 +0000 |
| Subject: | Re: [RFC] Enumerations, Round 2 | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112631@lists.php.net to get a copy of this message | ||
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?)
Also I think it's more natural if both enum types return a
zero-indexed-array of cases.
>
> https://wiki.php.net/rfc/enumerations
>
> The implementation is 98% complete; there's still a few lagging bits in reflection, and
> some opcache bugs that Ilija is still stomping on.
>
> There are a few outstanding questions listed that we would like feedback on. We're not
> entirely certain which direction to go with them, for reasons explained in the RFC. Input on those
> is especially welcome.
>
> Happy New Year. May it be enumerable.
>