Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119777
Message-ID: <1414702b-1f07-2a67-284a-6ba604f8b5e0@bastelstu.be>
Date: Wed, 29 Mar 2023 17:56:11 +0200
MIME-Version: 1.0
Content-Language: en-US
To: internals@lists.php.net
References: <CAF-mU4yTkfERD8zDW7HHxXBEevOnaa_OEPuEAJvJ9L38XA9d6w@mail.gmail.com>
 <CAPzBOBPDmiMs6hcYANh7pUVUHGJqyPK6vGvo4dgPFtYftTW67w@mail.gmail.com>
 <CAF-mU4xDj1oWx3RjnW+gQOxoVeiTx_dYkU_7xwgxE3cu0fvsRQ@mail.gmail.com>
 <CADyq6sJz=Ex6SS6wgOw20Lh8KV_JPhx_eYTCX=kY0eKCQXUhwQ@mail.gmail.com>
 <CAF-mU4wKZ+Zx9Qu3CYEF2GYakop+c0z4sot_3663w3nGb1bxOA@mail.gmail.com>
 <cd7e1084-c8bf-7738-e152-4a479615735b@php.net>
 <8bbe91fa-9f32-e2c6-91b9-e982d25042ed@bastelstu.be>
 <09A79162-3FB0-4443-9654-CCECE0B9865A@cschneid.com>
In-Reply-To: <09A79162-3FB0-4443-9654-CCECE0B9865A@cschneid.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [IDEA] allow extending enum
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 3/29/23 12:41, Christian Schneider wrote:
>> And to give a specific example from PHP 8.3: As part of the Randomizer additions RFC (https://wiki.php.net/rfc/randomizer_additions), PHP 8.3 got its first "natively included" enum (\Random\IntervalBoundary). This enum works together with the new Randomizer::getFloat() method to specify if the given min and max value may be returned or not.
>>
>> The Randomizer::getFloat() method internally includes switch statement that chooses the implementation based on the IntervalBoundary value given.
>>
>> If a user would be able to extend the IntervalBoundary enum, the method would not be able to make sense of it.
>>
>> The IntervalBoundary enum completely enumerates all four possible combinations for the two possible states for each of the two boundaries (2*2 = 4). By definition there is no other valid value.
> 
> I do understand the reason behind making Enums final and your example illustrates the point very well.
> 
> I still have a question I already asked in a different context: If there ever is the need to add a case to an Enum, was there any thought put into making this possible? Or is this categorically ruled out when using Enums?

Adding a case to an enum would certainly be considered a breaking change 
for folks that rely on having exhaustively handled all possible cases.

> Let’s look at a very, very hypothetical example: Imagine a Randomizer is much, much slower for certain boundaries and it is decided that some programs do not care about Closed/Open but instead care more about speed. So they would want to use something like IntervalBoundary::Fastest.

In this specific hypothetical example, the fastest case would be one of 
the existing 4 cases - an alias if you want to call it that.

Defining an alias is possible without breaking compatibility by 
leveraging class constants:

     <?php

     enum IntervalBoundary {
         case ClosedOpen;
         case ClosedClosed;
         case OpenClosed;
         case OpenOpen;

         public const Fastest = self::ClosedOpen;
     }

     var_dump(IntervalBoundary::ClosedOpen === IntervalBoundary::Fastest);

     function foo(IntervalBoundary $b) {
         var_dump($b);
     }

     foo(IntervalBoundary::Fastest);

-> https://3v4l.org/tT0Ho

Alternatively a method "public static function getFastest(): self" would 
be possible.

> As far as I understand such an addition would *never* be possible, right? This means people defining Enums have to be very very certain that no one will ever want another value, right?
> 

I believe the short answer to the last question is "Yes".

Best regards
Tim Düsterhus