Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110255
MIME-Version: 1.0
References: <CAJd4=YZd3Mh8sQjYxE-YfNim-CN1+j8oST2W+nykXDynC_KQiA@mail.gmail.com>
In-Reply-To: <CAJd4=YZd3Mh8sQjYxE-YfNim-CN1+j8oST2W+nykXDynC_KQiA@mail.gmail.com>
Date: Fri, 22 May 2020 18:25:58 +0200
Message-ID: <CADyq6sKn7ERUTmHfOSt6bOeWvFiS33ciaK7WZuLgktCs7AN3zg@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="0000000000003c735d05a63f16d1"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance
 signature checks on private methods
From: ocramius@gmail.com (Marco Pivetta)

--0000000000003c735d05a63f16d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Pedro,

On Fri, May 22, 2020 at 5:43 PM Pedro Magalh=C3=A3es <mail@pmmaga.net> wrot=
e:

> 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 private
> 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 and
> the child's method is non-static, or vice-versa
> - When a method has the same name as a parent's concrete private method a=
nd
> the child's method is abstract
>
> I have 2 open issues on the RFC that I would like to hear some opinions o=
n.
> - 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 th=
e
> BC break.
> - Whether or not to make an exception to this rule for magic methods. Giv=
en
> that this is widely to restrict object instantiation and cloning, it coul=
d
> make sense to still allow the use on those cases. However, I think that t=
he
> similar effect that can be achieved with "final protected function" would
> 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 P=
R
> (
> 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 type,
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 good
idea.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--0000000000003c735d05a63f16d1--