Hey Nikita, On Tue, Jun 16, 2020 at 11:05 AM Nikita Popov <nikita....@gmail.com> wrote:
> On Mon, Jun 15, 2020 at 10:43 PM Pedro Magalhães <m...@pmmaga.net> wrote: > > > Hi internals, > > > > I have opened the vote on the "Remove inappropriate inheritance signature > > checks on private methods" RFC. Which can be found here: > > > > https://wiki.php.net/rfc/inheritance_private_methods > > > > The voting period will end on 2020-06-29 22:00 UTC. > > > > Thanks to those who participated in the discussion and provided feedback. > > > > Voting no on this one, for the reason I previously mentioned on the PR: > While the abstract and static parts of the RFC make sense, the final part > does not (to me). Changing the behavior of private final just removes > existing functionality, without any clear benefit that I can see. What is > the problem that change tries to solve? Possibly missing in the RFC, but a parent class declaring a new `private` symbol shouldn't affect `private` API in child classes that may be pre-existing: helps backwards compatibility. > The original RFC could at least > make a consistency argument, but the final form, which converts an existing > special case into an even more convoluted special case, can not. Why is > __construct() exempted, but __clone() for example isn't, even though > similar considerations apply to it? > While `private final function __construct()` prevents child classes from making the constructor open, or accessing it (important for abstract types), `protected final function __clone()` achieves the same without having to rely on the `private` visibility modifier (https://3v4l.org/psR5F, for example). It is true that cloning is then possible from within a subtype, which is indeed a bit of a problem: https://3v4l.org/qupHR Maybe the magic methods would indeed all need to respect `final`, and we haven't considered all scenarios? These considerations were part of the previous discussion on the RFC - maybe should be added to its notes? Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
