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. 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). > > --Larry Garfield > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
