Re: [IDEA] allow extending enum
| From: | Christian Schneider | Date: | Wed, 29 Mar 2023 10:41:39 +0000 |
| Subject: | Re: [IDEA] allow extending enum | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-119765@lists.php.net to get a copy of this message | ||
Am 29.03.2023 um 11:55 schrieb Tim Düsterhus <tim@bastelstu.be>:
> On 3/29/23 11:42, Sebastian Bergmann wrote:
>> Am 29.03.2023 um 11:31 schrieb Rokas Šleinius:
>>> I wouldn't say removing the final attribute from enums actually "breaks"
>>> any functionality.
>> I am with Marco on this: removing the "finality" from enum would be a
>> major backward compatiblity break as it breaks a fundamental assumption
>> about enums.
>
> 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?
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.
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?
Regards,
- Chris