Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114129 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11568 invoked from network); 24 Apr 2021 16:39:36 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Apr 2021 16:39:36 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5CE481804CC for ; Sat, 24 Apr 2021 09:43:10 -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.1 required=5.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 24 Apr 2021 09:43:09 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2E67F5C00C5 for ; Sat, 24 Apr 2021 12:43:09 -0400 (EDT) Received: from imap8 ([10.202.2.58]) by compute4.internal (MEProxy); Sat, 24 Apr 2021 12:43:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=t627AvfSRyrOV5wuUaRrfegeZ/CJGm9oDmbhsGWf2 I0=; b=XMlW/QbnQJjZmOH8OVGAa5NiCpTeuj1eK2+Dsdj58iV1EciH5K8tAJ1pr l60WXDhEcca9/9KkBg6y/KWsiOdMH6UYgF+np/sCS2kdfp6ygHEqaodaChPL3he/ W+NSXKuJF/5jYM0WV59yU4Ml+uZ6XbpMPUCn/5y9B7Mi4LID4d+3O+jzn/OQ3oa6 lO2Qo9J6kww+k2LG0xE5Mo3lIrp+gw6JT0ABmw0L9mIImwuzsfaJ+nzsdHhEhh1K b+LfuXFXm2hhAqmhYZEZig7tYpkkjlA0xW0mRu5p1fW0//FhYQfDHpsVv/gm6Ss+ mwGtCg04PKbDkUomEru3QA/2wy+MQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddugedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfn rghrrhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrd gtohhmqeenucggtffrrghtthgvrhhnpeeggeehgfetjeehgefggefhleeugefgtdejieev vdethfevgeeuudefleehvdetieenucffohhmrghinhepphhhphdrnhgvthenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghr fhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 911A03A05A1; Sat, 24 Apr 2021 12:43:08 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b Mime-Version: 1.0 Message-ID: <37ae9b23-dde1-4910-86b0-fa8f29544404@www.fastmail.com> In-Reply-To: References: Date: Sat, 24 Apr 2021 11:42:48 -0500 To: "php internals" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: [RFC][Draft] Sealed Classes From: larry@garfieldtech.com ("Larry Garfield") On Sat, Apr 24, 2021, at 6:00 AM, Saif Eddin Gmati wrote: > A major behavior i wanted to discuss is how should sealed interfaces=20= > work, and specially around `Throwable` which is currently sealed to=20= > only `Error` and `Exception`, but allows other interfaces to extend it= ,=20 > and other classes to implement it as long as they extend `Error` or=20= > `Exception` ( or another class that does so ). >=20 > As per the current proposal, if `Throwable` is to be declared `sealed`= ,=20 > permitting only `Error` and `Exception`, it won't be possible to exten= d=20 > it, resulting in a major BC-break, considering that too many libraries= =20 > extend this interface in their own `ExceptionInterface`. >=20 > To work around this, there's two solution: >=20 > 1. don't declare `Throwable` sealed and keep it as a special case. > 2. interfaces declared sealed, can be extended by other interfaces,=20= > however, classes that implement either the sealed interface directly,=20= > or via another interface, have to extend one of the classes the sealed= =20 > interface permits.=20 >=20 > The second solution will allow declaring `Throwable` sealed, and would= =20 > bring complete consistency between internally sealed symbols, and user= =20 > land, without any BC breaks, and IMHO, it doesn't hurt as at the end,=20= > no one will be able to implement `Throwable` without extending the=20 > permitted classes.=20 >=20 > Note: with the second solution, if an interface is sealed and permits=20= > only 2 classes which are final, and you extend that interface into=20 > another, there's no way you can actually implement your new interface,= =20 > and i will be as if you just declared a final interface. >=20 >=20 > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origin= al Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90= > On Saturday, April 24, 2021 11:55 AM, Saif Eddin Gmati=20 > wrote: >=20 > > Hello Internals, > >=20 > > I'm sending this email to open discussion about sealed classes, inte= rfaces, and traits feature for PHP 8.1. > >=20 > > I have create a Draft RFC here: https://wiki.php.net/rfc/sealed_clas= ses > >=20 > > A major concern for few people have been the syntax, in which it int= roduces 2 new keywords into the languages, therefor, i have added a sect= ion about alternative syntax which could be used to avoid this problem. > >=20 > > Regards, > >=20 > > Saif. 1) I am generally supportive of this concept. 2) For exceptions, I'm honestly fine with Throwable just being weird. I= t already is, so letting it stay weird doesn't hurt anything. 3) The syntax examples mention traits, but nothing else in the spec talk= s about traits. What does sealed mean on a trait? I assume "can only b= e 'use'd by these classes", but that should be explicit. 4) I'm on team Attributes for the syntax, for two main reasons. One, it= eliminates the need for a new keyword entirely. It would only require = defining a new built-in class, and that class could be namespaced (per t= he likely-to-pass namespace policy) so that it is unlikely to conflict w= ith anything at all. Two, I find it visually better as it it is not par= t of the type system per se, but a sort of meta-type system. Which is e= xactly where Attributes fit. (Basically what Levi said.) 5) If this passes, then combined with Nikita's "new in intializiers" RFC= (https://wiki.php.net/rfc/new_in_initializers) it would effectively giv= e us ADTs/Union Types by a different syntax. One could argue which synt= ax is better or more convenient (I'm not sure which I favor myself), but= I'm just calling out that this would give us effectively the same resul= t in terms of capability. --Larry Garfield