Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110601
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CAF+90c8zb1kw9PoSwZ1p_QQpaXcCX4W0-iAvXrY0-5PwEbtgng@mail.gmail.com>
Date: Tue, 16 Jun 2020 11:55:52 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <6B53DD33-5638-4064-BCEB-7F0B7E2184BA@newclarity.net>
References: <9D1E1E08-7DD5-4FD3-B08E-58254CC75FC5@newclarity.net>
 <CAF+90c8zb1kw9PoSwZ1p_QQpaXcCX4W0-iAvXrY0-5PwEbtgng@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] Remove LSP checks on static methods?
From: mike@newclarity.net (Mike Schinkel)

> On Jun 16, 2020, at 3:50 AM, Nikita Popov <nikita.ppv@gmail.com> =
wrote:
>=20
> On Tue, Jun 16, 2020 at 8:59 AM Mike Schinkel <mike@newclarity.net> =
wrote:
> Hi internals,
>=20
> Given that there appears to be some appetite to reduce checks for =
inappropriate signatures[1] I am wondering if anyone has strong opinions =
=E2=80=94 pro or con =E2=80=94 on removing checks for static methods?
>=20
> My primary use-case where I would like to see checked relaxed is for =
static methods used as factory methods[2].
>=20
> Per [3] it seems that all but the least upvoted answer argues that LSP =
applies to instances, not static methods.=20
>=20
> Per [4] it seems that all upvoted answers agree that constructors =
should not be constrained by LSP, and since a factory method is a form =
of a constructor it would seem that if constructors do not require LSP =
then factory methods would not either.
>=20
> Does anyone see any issues with relaxing these checks for static =
methods that would have them downvote an RFC on the topic?
>=20
> Hi Mike,
>=20
> The problem here is that static methods signatures are subject to LSP =
if they are used in conjunction with late static binding (LSB):
>=20
> class A {
>     public static function test() {
>         static::method();
>         // May call A::method(), B::method() or any child.
>         // Signature must match for this to be sensible!
>     }
> }
> class B extends A {
> }
>=20
> I do agree that the current situation is sub-optimal, because =
certainly not all static methods actually are used with LSB. But we do =
not presently distinguish these cases.
>=20
> If that problem can be addressed in some way, then I agree that =
(non-LSB) static methods should be exempt from LSP, just like =
constructors are.

Thank you for your response Nikita. Much appreciated.

Would it be reasonable to consider moving the check for incompatible =
signature to the first time a method is called using `static::` rather =
than where the method is declared?  That would bypass the need for a new =
keyword and any confusion and BC a new keyword might create.

Also, I think would assume you add need to add a flag to the child =
methods when they are declared so as to know if they match their parent =
or not?

class A {
    public static function test() {
        static::method();                             // This would work
        $b =3D B::create(['foo'=3D>'bar']);          // This would work
        $c =3D C::create(123,['foo'=3D>'baz']);   // This would work
        static::create();                                // Error could =
be throw here?
    }
}
class B extends A {
    public static function method() {
    }
    public static function create(array $args) {
    }
}
class C extends B {
    public static function method() {
    }
    public static function create(int$id, array $args) {
    }
}

-Mike=