Le 05/12/2020 à 00:24, Larry Garfield a écrit :
Greetings, denizens of Internals!
Ilija Tovilo and I have been working for the last few months on adding support
for enumerations and algebraic data types to PHP. This is a not-small task, so
we've broken it up into several stages. The first stage, unit enumerations,
are just about ready for public review and discussion.
The overarching plan (for context, NOT the thing to comment on right now) is
here: https://wiki.php.net/rfc/adts
The first step, for unit enumerations, is here:
https://wiki.php.net/rfc/enumerations
There's still a few bits we're sorting out and the implementation is mostly
done, but not 100% complete. Still, it's far enough along to start a
discussion on and get broader feedback on the outstanding nits.
I should note that while the design has been collaborative, credit for the
implementation goes entirely to Ilija. Blame for any typos in the RFC itself
go entirely to me.
*dons flame-retardant suit*
Hello !
I fully support all this initiative. Here is a first question, regarding
the enum::cases() static method:
> If the enumeration has no primitive equivalent, the array will be
packed (indexed sequentially starting from 0). If the enumeration has a
primitive equivalent, the keys will be the corresponding primitive for
each enumeration. If the enumeration is of type |float|, the keys will
be rendered as strings. (So a primitive equivalent of |1.5| will result
in a key of |“1.5”|.)
Does this mean that an enum can't have two cases with the same primitive
value ? I would very much being able to do so, for example, when you
change a name and want to keep the legacy for backward compatibility.
I think that ::cases() should always return an array/iterable without
keys, and let userland write their own code to create hashmaps with
those when they need it. I think that having one case (non primitive
cases) that doesn't yield string keys and the other (primitive cases)
which holds string keys may create a confusion because behavior is
different.
If behavior is different, this would mean you couldn't mix primitive and
non primitive cases on the same enum, which, why not couldn't we do that?
Regards,
Pierre
