Hi Marco, Thanks for the feedback.
About the sealed type example, it is true that `final protected` wouldn't achieve the same thing. But as an attempt to provide an alternative design, wouldn't an union type of the desired children be a better choice? I can see some usefulness in it but IMHO, it is supported by a broken behavior, it doesn't make sense to talk about private symbol overrides. That shouldn't be a thing. With that said, I don't think the RFC has to be all or nothing, but we would leave an exception behind. About lifting the restriction only to magic methods, I don't really like that approach. Anything that makes them more special feels like a step in the wrong direction. If we were to lift that restriction, I would say that it should be lifted for any method, leaving the RFC to deal only with the static and abstract cases. About the serialization example, I think that goal is equally possible to achieve with final protected. Regards, Pedro On Fri, May 22, 2020 at 5:25 PM Marco Pivetta <ocram...@gmail.com> wrote: > Hey Pedro, > > On Fri, May 22, 2020 at 5:43 PM Pedro Magalhães <m...@pmmaga.net> wrote: > >> Hi internals, >> >> I want to put up for discussion an RFC ( >> https://wiki.php.net/rfc/inheritance_private_methods) that proposes to >> remove some inappropriate signature checks that are still done on private >> methods. Namely, those checks are: >> >> - When a method has the same name as a parent's final private method >> - When a method has the same name as a parent's static private method and >> the child's method is non-static, or vice-versa >> - When a method has the same name as a parent's concrete private method >> and >> the child's method is abstract >> >> I have 2 open issues on the RFC that I would like to hear some opinions >> on. >> - Whether or not to issue a compiler warning whenever "final private >> function" is used, to alert the user that it will not achieve what that >> construct is currently used for. The disadvantage of introducing it is the >> BC break. >> - Whether or not to make an exception to this rule for magic methods. >> Given >> that this is widely to restrict object instantiation and cloning, it could >> make sense to still allow the use on those cases. However, I think that >> the >> similar effect that can be achieved with "final protected function" would >> cover most of the cases. And if we open up that exception for magic >> methods, for the sake of clarity maybe we should just keep the "final >> private" behavior on all methods and just change the static and the >> abstract behaviors. Some discussion on this subject can be found on the >> PR ( >> https://github.com/php/php-src/pull/5401) for this RFC. >> > > Overall, this RFC breaks some design capabilities that are within the > language, specifically around `__`-prefixed methods in the language. > > For instance, I design (on purpose) sealed types as following: > > ```php > abstract class Email > { > final private function __construct() {} > public static function business(): Business { > return new Business(); > } > public static function personal(): Personal { > return new Personal(); > } > } > > final class Business extends Email {} > final class Personal extends Email {} > ``` > > The above approach guarantees that no further subtypes exist for `Email`, > other than `Business` or `Personal`, effectively forming a safe union type, > which can only be broken by reflection. > > In addition to that, I often prevent serialization of types that are not > intended to be serialized (when not final): > > ```php > abstract class InMemorySecret > { > final private function __sleep() {} > } > ``` > > Effectively, the `final` modifier applies to `private` symbols too, and > prevents child classes from deviating from imposed design constraints. > > It is **intentional** for `private` symbol overrides to not compile in > these cases. > > Both of the above examples only apply to special/magic methods: I can see > and understand that for custom methods this RFC may be valid, and adding a > further refinement to lift the restriction only on custom methods is a good > idea. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > >
