Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110280
MIME-Version: 1.0
References: <CAJd4=YZd3Mh8sQjYxE-YfNim-CN1+j8oST2W+nykXDynC_KQiA@mail.gmail.com>
 <CADyq6sKn7ERUTmHfOSt6bOeWvFiS33ciaK7WZuLgktCs7AN3zg@mail.gmail.com> <CAJd4=YYt46c4tyuaRxgv6VTrerSZsNG-G4OUYEHPPrLOEYDSew@mail.gmail.com>
In-Reply-To: <CAJd4=YYt46c4tyuaRxgv6VTrerSZsNG-G4OUYEHPPrLOEYDSew@mail.gmail.com>
Date: Tue, 26 May 2020 16:46:22 +0200
Message-ID: <CADyq6sK8tJnV9igmeogcoGOHhVS=84R4V37KoDy15K-1xo49pg@mail.gmail.com>
To: =?UTF-8?Q?Pedro_Magalh=C3=A3es?= <mail@pmmaga.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007d010c05a68e2945"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance
 signature checks on private methods
From: ocramius@gmail.com (Marco Pivetta)

--0000000000007d010c05a68e2945
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Pedro,

On Tue, May 26, 2020, 16:34 Pedro Magalh=C3=A3es <mail@pmmaga.net> wrote:

> Hi Marco,
>
> Thanks for the feedback.
>
> About the sealed type example, it is true that `final protected` wouldn't
> achieve the same thing. But as an attempt to provide an alternative desig=
n,
> wouldn't an union type of the desired children be a better choice?
>

Difficult without having type aliases for union types: possible with tools
like psalm, but fragile and easy to work around for less experienced devs.
The construct in my example is instead very hard to avoid unless you know
about `ReflectionClass#newInstanceWithoutConstructor()`

it is supported by a broken behavior
>

Not really: the `__`-prefixed methods are indirectly part of the object's
API, and I seal them off by design, guiding consumers of my implementation
& type.

About lifting the restriction only to magic methods, I don't really like
> that approach. Anything that makes them more special feels like a step in
> the wrong direction. If we were to lift that restriction, I would say tha=
t
> it should be lifted for any method, leaving the RFC to deal only with the
> static and abstract cases.
>

Magic methods are indeed a pain in the language: I'm trying to make the
best use for them (there's already enough bad usage out there).


About the serialization example, I think that goal is equally possible to
> achieve with final protected.
>

Good point!

Considering that, as far as I know, only the constructor remains "special".

>

--0000000000007d010c05a68e2945--