Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110279
MIME-Version: 1.0
References: <CAJd4=YZd3Mh8sQjYxE-YfNim-CN1+j8oST2W+nykXDynC_KQiA@mail.gmail.com>
 <CADyq6sKn7ERUTmHfOSt6bOeWvFiS33ciaK7WZuLgktCs7AN3zg@mail.gmail.com>
In-Reply-To: <CADyq6sKn7ERUTmHfOSt6bOeWvFiS33ciaK7WZuLgktCs7AN3zg@mail.gmail.com>
Date: Tue, 26 May 2020 15:34:01 +0100
Message-ID: <CAJd4=YYt46c4tyuaRxgv6VTrerSZsNG-G4OUYEHPPrLOEYDSew@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003d902b05a68dfd95"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance
 signature checks on private methods
From: mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)

--0000000000003d902b05a68dfd95
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 design,
wouldn't an union type of the desired children be a better choice?
I can see some usefulness in it but IMHO, it is supported by a broken
behavior, it doesn't make sense to talk about private symbol overrides.
That shouldn't be a thing.
With that said, I don't think the RFC has to be all or nothing, but we
would leave an exception behind.

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 that
it should be lifted for any method, leaving the RFC to deal only with the
static and abstract cases.

About the serialization example, I think that goal is equally possible to
achieve with final protected.

Regards,
Pedro

On Fri, May 22, 2020 at 5:25 PM Marco Pivetta <ocramius@gmail.com> wrote:

> Hey Pedro,
>
> On Fri, May 22, 2020 at 5:43 PM Pedro Magalh=C3=A3es <mail@pmmaga.net> wr=
ote:
>
>> Hi internals,
>>
>> I want to put up for discussion an RFC (
>> https://wiki.php.net/rfc/inheritance_private_methods) that proposes to
>> remove some inappropriate signature checks that are still done on privat=
e
>> methods. Namely, those checks are:
>>
>> - When a method has the same name as a parent's final private method
>> - When a method has the same name as a parent's static private method an=
d
>> the child's method is non-static, or vice-versa
>> - When a method has the same name as a parent's concrete private method
>> and
>> the child's method is abstract
>>
>> I have 2 open issues on the RFC that I would like to hear some opinions
>> on.
>> - Whether or not to issue a compiler warning whenever "final private
>> function" is used, to alert the user that it will not achieve what that
>> construct is currently used for. The disadvantage of introducing it is t=
he
>> BC break.
>> - Whether or not to make an exception to this rule for magic methods.
>> Given
>> that this is widely to restrict object instantiation and cloning, it cou=
ld
>> make sense to still allow the use on those cases. However, I think that
>> the
>> similar effect that can be achieved with "final protected function" woul=
d
>> cover most of the cases. And if we open up that exception for magic
>> methods, for the sake of clarity maybe we should just keep the "final
>> private" behavior on all methods and just change the static and the
>> abstract behaviors. Some discussion on this subject can be found on the
>> PR (
>> https://github.com/php/php-src/pull/5401) for this RFC.
>>
>
> Overall, this RFC breaks some design capabilities that are within the
> language, specifically around `__`-prefixed methods in the language.
>
> For instance, I design (on purpose) sealed types as following:
>
> ```php
> abstract class Email
> {
>     final private function __construct() {}
>     public static function business(): Business {
>         return new Business();
>     }
>     public static function personal(): Personal {
>         return new Personal();
>     }
> }
>
> final class Business extends Email {}
> final class Personal extends Email {}
> ```
>
> The above approach guarantees that no further subtypes exist for `Email`,
> other than `Business` or `Personal`, effectively forming a safe union typ=
e,
> which can only be broken by reflection.
>
> In addition to that, I often prevent serialization of types that are not
> intended to be serialized (when not final):
>
> ```php
> abstract class InMemorySecret
> {
>     final private function __sleep() {}
> }
> ```
>
> Effectively, the `final` modifier applies to `private` symbols too, and
> prevents child classes from deviating from imposed design constraints.
>
> It is **intentional** for `private` symbol overrides to not compile in
> these cases.
>
> Both of the above examples only apply to special/magic methods: I can see
> and understand that for custom methods this RFC may be valid, and adding =
a
> further refinement to lift the restriction only on custom methods is a go=
od
> idea.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

--0000000000003d902b05a68dfd95--