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