Re: [RFC] Enumerations, Round 2

From: 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

« previous php.internals (#112636) next »