Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110726
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>
 <CAF+90c_e2Le66Ca2o1T1ypY2bidpLi0ZiYRqYjjZuVWccc9yNA@mail.gmail.com> <CAAwdEzA-8K_vYva=EucQG0PECQOeidogtybRKK6sbF6zBjYNqg@mail.gmail.com>
In-Reply-To: <CAAwdEzA-8K_vYva=EucQG0PECQOeidogtybRKK6sbF6zBjYNqg@mail.gmail.com>
Date: Thu, 25 Jun 2020 14:54:40 +0200
Message-ID: <CAF+90c_h-HpnW5m=mOmZxTrPrgGAw_Co+168uqtmQu=JpkL49w@mail.gmail.com>
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, =?UTF-8?Q?Pedro_Magalh=C3=A3es?= <mail@pmmaga.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006d1c0905a8e819eb"
Subject: Re: [PHP-DEV] [VOTE] Remove inappropriate inheritance signature
 checks on private methods
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000006d1c0905a8e819eb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 19, 2020 at 1:30 PM Alexandru P=C4=83tr=C4=83nescu <drealecs@gm=
ail.com>
wrote:

> On Fri, Jun 19, 2020 at 12:17 PM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> >
> > 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.n=
et>
> 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 remove=
s
> > >> 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.
> > >
> >
> > 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 withou=
t
> > > 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 possibl=
y
> > 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.
> >
>
> From how I understood it, right now "private final" cannot possibly
> have a real world use-case for other cases except for __construct and
> possibly for other fixed named magic methods like __clone.
>
> Someone can use it in a parent class and a child class developed by
> someone would have a restriction on what private method it can use to
> do his own private stuff.
> In reality, that's easily circumvented by choosing a different private
> name but this RFC will allow the user to use his prefered name for the
> private method. That's mainly why it's useful from my point of view.
>

I agree that the "private final" concept is only useful for cases where the
engine assigns special meaning to the method name, and can see the
rationale for not allowing it on normal (non-magic) methods.

I've dropped my "no" vote on the RFC. I don't like the specific decision on
this particular aspect, but not enough to block the rest.

Regards,
Nikita

--0000000000006d1c0905a8e819eb--