Hi! There's a hypothetical (based on a similar real world problem that I am facing) example for the use of extending enums in the OP.
And I don't suppose Tim was arguing for not allowing enum extendability, but rather contributing a real world example where users who were having some totally legal fun hacking around with internal PHP code would break said internal PHP code. Which may or may not be a big deal from my uneducated point of view, just saying :) And all could be prevented just by adding a `final` statement to the definition of `IntervalBoundary`. On Wed, 29 Mar 2023 at 13:42, Christian Schneider <cschn...@cschneid.com> wrote: > > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
