Le 05/12/2020 à 12:14, Markus Fischer a écrit :
Hi,
On 05.12.20 10:22, Pierre R. wrote:
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?
I've no strong feelings and I think your idea makes sense.
But I would argue, of course without having hard facts, that the
_majority_ will have the use-case for a 1:1, aka array with key =>
value, mapping.
Thus I would argue that having (considering your proposal being added)
still such functionality would be useful for a very wide-audience
without everyone having to reinvent a helper method to use the iterable.
I agree with that last statement about wide-audience usefulness,
nevertheless my opinion is that it's not about being useful to the most
but bring consistency at the language level. If for consistency I have
to write an array_map() call whenever I need a choices list, I'm good
with that. Moreover, bringing enum is a thousands times more useful than
having a sugar candy method for building hashmaps !
There are many use cases you'd want an hashmap out of those enums, but
each use case will probably differ in subtle ways. I'd more comfortable
with a coherent behavior that everyone will understand easily, with no
behavior subtleties, and each user implement its need on this side.
Why not, in that case, just add another method than ::cases(), such as,
I don't know, ::to[Hash]Map() for example ?
Regards,
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
