Re: [RFC][Draft] Sealed Classes

From: Date: Sat, 24 Apr 2021 15:59:02 +0000
Subject: Re: [RFC][Draft] Sealed Classes
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-114128@lists.php.net to get a copy of this message
> Doesn't this violate the principle: It should be possible to add new features without > touching old code? This depends on which syntax is picked, both for and attribute syntax will be completely BC. using sealed+permits or permits only will result in these keywords being reserved, so classes named Sealed or Permits will not work in PHP 8..1. > Isn't namespace-internal access a better feature for the same purpose? That is, only > allows a class to be extended within the same namespace. No, this is a different feature, sealed classes can permit classes in a completely different namespace, and restrict inheritance to a per-defined list of classes. If we would allow inheritance in the same namespace, it's extremely easy to get around it: ``` namespace Lib {   abstract class MyProxy implements PrivateFooInterface {} } namespace App {   class MyFooImplementation extends \Lib\MyProxy {     // ...   } } ``` while it is possible to get around sealed, or even final keywords ( https://github.com/dg/bypass-finals/blob/master/src/BypassFinals.php ), bypassing private classes/interface is much easier, and doesn't require any hacks. ---- On Sat, 24 Apr 2021 16:52:20 +0100 Olle Härstedt <olleharstedt@gmail.com> wrote ---- 2021-04-24 12:56 GMT, Pierre <mailto:pierre-php@processus.org>: > Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit : >> Hello Internals, >> >> I'm sending this email to open discussion about sealed classes, >> interfaces, and traits feature for PHP 8.1. >> >> I have create a Draft RFC here: >> https://wiki.php.net/rfc/sealed_classes >> <https://wiki.php.net/rfc/sealed_classes> >> >> A major concern for few people have been the syntax, in which it >> introduces 2 new keywords into the languages, therefor, i have added a >> section about alternative syntax which could be used to avoid this >> problem. >> >> Regards, >> >> Saif. 1) Doesn't this violate the principle: It should be possible to add new features without touching old code? 2) Isn't namespace-internal access a better feature for the same purpose? That is, only allows a class to be extended within the same namespace. Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

« previous php.internals (#114128) next »