Re: [RFC] Enumerations, Round 2

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 >