Am 29.03.2023 um 11:55 schrieb Tim Düsterhus <t...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
