Re: [IDEA] allow extending enum

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 <cschneid@cschneid.com> wrote: > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >