Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110576
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: Tue, 16 Jun 2020 11:20:25 +0100
Message-ID: <CAJd4=YaJJNJJEfdgfoakDFsdLd7pxmK8qKme607nj4L-BHonXA@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fd389e05a830e41f"
Subject: Re: [PHP-DEV] [VOTE] Remove inappropriate inheritance signature
 checks on private methods
From: mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)

--000000000000fd389e05a830e41f
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 16, 2020 at 10:19 AM Marco Pivetta <ocramius@gmail.com> wrote:

> On Tue, Jun 16, 2020 at 11:05 AM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
>> 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).
>

In my opinion, the example given by Marco on the discussion thread about
sealed types is a good argument on why __construct should keep the behavior
(https://externals.io/message/110251#110255). You would need to write a lot
of convoluted code to achieve the same behavior as you currently can.

It is true that cloning is then possible from within a subtype, which is
> indeed a bit of a problem: https://3v4l.org/qupHR
>

 I don't find that problematic. If ultimately your goal is to disallow
cloning, doing it by visibility constraints is cheaper and covers 99% of
the cases but it's still possible to enforce it even for the child class by
throwing: https://3v4l.org/U1LMQ

Regards,
Pedro

--000000000000fd389e05a830e41f--