Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112687
To: internals@lists.php.net
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com>
 <8aa05350-05fc-df9d-e5d6-fa0f4feb57ba@alec.pl>
 <fdbc8779-de22-46a1-ab6e-e3cfb34565b4@www.fastmail.com>
Message-ID: <c3dfee4f-6f54-9b4a-a599-fb016ed6a110@alec.pl>
Date: Wed, 30 Dec 2020 22:24:05 +0100
MIME-Version: 1.0
In-Reply-To: <fdbc8779-de22-46a1-ab6e-e3cfb34565b4@www.fastmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2
From: alec@alec.pl (Aleksander Machniak)

On 30.12.2020 21:21, Larry Garfield wrote:
>> enum Suit {
>>   case Hearts = 'H';
>>   case Diamonds = 'D';
>>   case Clubs = 'C';
>>   case Spades = 'S';
>> }
>>
>> 'H' === Suit::Hearts->value; // true
>> 'Hearts' === Suit::Hearts->value; // false
> 
> That's a possibility we've been kicking around.  I'm considering it, Ilija doesn't care for it. :-)  What's your argument in favor?

My argument is that, from an end-user perspective, I don't really see
why Unit and Scalar enums have to have different "API" at this point.
I'm talking about ":string"/":int" in the enum definiton as well as
->value and ->from().

-- 
Aleksander Machniak
Kolab Groupware Developer        [https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com