Re: [RFC][Draft] Sealed Classes
| From: | Saif Eddin Gmati | 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