On 03.01.21 11:56, Marc wrote: > On 29.12.20 16:42, Larry Garfield wrote: >> 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. > I don't have a really good use-case for float values. It just seems > weird to me that a ScalarEnum doesn't support all scalars. > > Using the enum value as array key for `cases()` works with your current > proposal but if we later want to allow floats, bool whatever then we got > a food gun.
Forgot to mention on (virtiually) adding generics to the game the method `cases(): array;`<http://www.php.net/array>would be described as `cases(): array<int, static>;` on UnitEnum but `cases(): array<string|int, static>;` on ScalarEnum which is not compatible for reasons and I think (even if not yet possible with PHP) such things needs to be considered on producing clean interfaces. > > You already provide a lookup mechanism with `MyEnum::from()` - I don't > see a real use-case for proving a pre build map. The main use case I see > is to list all possible enum values but this doesn't require a map and a > zero-indexed-array would also be more performant with packed arrays > (correct me if I'm wrong). > Thanks, Marc >> --Larry Garfield >>
