Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119765 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38517 invoked from network); 29 Mar 2023 10:41:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Mar 2023 10:41:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 239DA18054A for ; Wed, 29 Mar 2023 03:41:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15623 212.45.192.0/19 X-Spam-Virus: No X-Envelope-From: Received: from mail.gna.ch (mail.gna.ch [212.45.196.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 29 Mar 2023 03:41:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by darkcity.gna.ch (Postfix) with ESMTP id 146A83A1DCF for ; Wed, 29 Mar 2023 12:41:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mail.gna.ch ([127.0.0.1]) by localhost (darkcity.gna.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhfSsWAsQSXa for ; Wed, 29 Mar 2023 12:41:41 +0200 (CEST) Received: from smtpclient.apple (unknown [194.169.219.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 44CC53A1D7A for ; Wed, 29 Mar 2023 12:41:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Date: Wed, 29 Mar 2023 12:41:39 +0200 References: <8bbe91fa-9f32-e2c6-91b9-e982d25042ed@bastelstu.be> To: PHP internals In-Reply-To: <8bbe91fa-9f32-e2c6-91b9-e982d25042ed@bastelstu.be> Message-ID: <09A79162-3FB0-4443-9654-CCECE0B9865A@cschneid.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) Subject: Re: [PHP-DEV] [IDEA] allow extending enum From: cschneid@cschneid.com (Christian Schneider) Am 29.03.2023 um 11:55 schrieb Tim D=C3=BCsterhus : > On 3/29/23 11:42, Sebastian Bergmann wrote: >> Am 29.03.2023 um 11:31 schrieb Rokas =C5=A0leinius: >>> 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. >=20 > 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. >=20 > The Randomizer::getFloat() method internally includes switch statement = that chooses the implementation based on the IntervalBoundary value = given. >=20 > If a user would be able to extend the IntervalBoundary enum, the = method would not be able to make sense of it. >=20 > The IntervalBoundary enum completely enumerates all four possible = combinations for the two possible states for each of the two boundaries = (2*2 =3D 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=E2=80=99s 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