Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110680
MIME-Version: 1.0
References: <CAJd4=YbamFA0LghzZdfLExPzgqZ3Q=snON+PGf9CkbAd442ACQ@mail.gmail.com>
 <CAF+90c8pGNOuqmQ00SYnXXZOhWMUWuC59E_J_6j8HQxGBQzLNQ@mail.gmail.com> <CADyq6sKsrV0PQA+CerOpWrw01wLQZTTSByVa0A_vON4dGT1ctA@mail.gmail.com>
In-Reply-To: <CADyq6sKsrV0PQA+CerOpWrw01wLQZTTSByVa0A_vON4dGT1ctA@mail.gmail.com>
Date: Fri, 19 Jun 2020 11:17:11 +0200
Message-ID: <CAF+90c_e2Le66Ca2o1T1ypY2bidpLi0ZiYRqYjjZuVWccc9yNA@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: =?UTF-8?Q?Pedro_Magalh=C3=A3es?= <mail@pmmaga.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a8bc2505a86c5cc2"
Subject: Re: [PHP-DEV] [VOTE] Remove inappropriate inheritance signature
 checks on private methods
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000a8bc2505a86c5cc2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 16, 2020 at 11:19 AM Marco Pivetta <ocramius@gmail.com> wrote:

> 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=C3=A3es <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 par=
t
>> does not (to me). Changing the behavior of private final just removes
>> existing functionality, without any clear benefit that I can see. What i=
s
>> 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.
>

Right, and I totally agree with that part insofar as it concerns
static/abstract handling. However, "private final" in particular is not an
accidental addition in the base class, it's an explicit design decision to
forbid certain behaviors in child classes.

 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?
>

Or ... we could just not change this part of the behavior at all :) If we
acknowledge that this is definitely useful for constructors and possibly
useful for cloning, then maybe it is useful for other things as well? I
still haven't heard a reason *why* we would want to do this change (not the
general change, but specifically the "private final" one).

This stuff really isn't super important to me, and I'd be happy to
sacrifice this functionality in the name of the greater good, but I
honestly don't understand what that greater good is in this case. It seems
like a strict loss in functionality.

Regards,
Nikita

--000000000000a8bc2505a86c5cc2--