Re: [VOTE] Remove inappropriate inheritance signature checks on private methods

From: Date: Tue, 16 Jun 2020 09:19:38 +0000
Subject: Re: [VOTE] Remove inappropriate inheritance signature checks on private methods
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-110572@lists.php.net to get a copy of this message
Hey Nikita, On Tue, Jun 16, 2020 at 11:05 AM Nikita Popov <nikita.ppv@gmail.com> wrote: > On Mon, Jun 15, 2020 at 10:43 PM Pedro Magalhães <mail@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/

« previous php.internals (#110572) next »