Re: [VOTE] Remove inappropriate inheritance signature checks on private methods
| From: | Marco Pivetta | 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/