Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112420
To: internals@lists.php.net
References: <d1c4689e-9120-4e90-837c-a1b3eac63cd6@www.fastmail.com>
Message-ID: <6cdd2d8c-39ea-c3a3-5f42-e355dc601539@processus.org>
Date: Sat, 5 Dec 2020 10:22:34 +0100
MIME-Version: 1.0
In-Reply-To: <d1c4689e-9120-4e90-837c-a1b3eac63cd6@www.fastmail.com>
Content-Type: multipart/alternative;
 boundary="------------A38C8419F504938778308935"
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] Enumerations
From: pierre-php@processus.org ("Pierre R.")

--------------A38C8419F504938778308935
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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


--------------A38C8419F504938778308935--