Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113537
MIME-Version: 1.0
References: <CAOkcCt88CD0aAZ=+5Oi7SeW7E3Z1OLvai=s4s-MUQq6QwD1z5w@mail.gmail.com>
 <CAKuGYLRZEieMfOe1eYYkZnTaWm8yGHP8UbrEfwrg4ZReDX3NTQ@mail.gmail.com>
 <d7c8ffb2-8eea-0fa3-a35f-8333c88a12fc@gmail.com> <CAKuGYLQPoOkiJsVfAL20uQVbkqMQohBOVFe3X7K-Eko1uPSAsw@mail.gmail.com>
In-Reply-To: <CAKuGYLQPoOkiJsVfAL20uQVbkqMQohBOVFe3X7K-Eko1uPSAsw@mail.gmail.com>
Date: Mon, 15 Mar 2021 14:35:59 +0100
Message-ID: <CAF+90c-Gp=zV5EpUM2f1wb_EwW4k1bPMUExrEiHnu7B=EwVpmg@mail.gmail.com>
To: Matthew Brown <matthewmatthew@gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008899f805bd93554a"
Subject: Re: [PHP-DEV] [RFC Proposal] Allow methods to 'become' static
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000008899f805bd93554a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 15, 2021 at 2:16 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> On Sun, 14 Mar 2021 at 18:09, Rowan Tommins <rowan.collins@gmail.com>
> wrote:
>
> > Are you saying that having the parent::getSomeInt() call fail would be
> > problematic?
> >
> >
>  Yes, that's where this becomes unsound =E2=80=93 you can call the child =
method
> statically, but the parent call assumes a dynamic instance.
>
> This is just my perspective (as someone building a tool that helps preven=
t
> people from shooting themselves in the foot), but PHP should not allow
> _more_ unsound behaviour than it already does.
>

I'm not sure I follow your point. The fact that something is compatible,
does not mean that you can just blindly perform a forwarding call. For
example, consider this:

class A {
    public function method(string $x) {}
}

class B extends A {
    public function method(string|int $x) {
        parent::method($x);
    }
}

B::method() is compatible with A::method() from a typesystem perspective.
But that doesn't mean that a parent::method() call will work. The above
code is simply an implementation bug in B::method(), but doesn't say
anything fundamental about the compatibility of the signatures. I would
argue that the same holds in your example.

Disclaimer: I have some serious doubts that allowing non-static->static
changes is worthwhile, I just don't see why it would be outright unsound.

Regards,
Nikita

--0000000000008899f805bd93554a--