Re: [RFC Proposal] Allow methods to 'become' static
On Mon, 15 Mar 2021 at 09:36, Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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
>
Ah OK! When I say "unsound" I mean "the type system implied by PHP's
behaviour allows code that a static analysis tool cannot catch".
It's trivial for a static analysis tool to find a bug in your example:
https://psalm.dev/r/3cd498b539
If PHP changed to allow child methods of instance methods to become static,
static analysis tools could follow suit, but that would invite undetectable
unsound behaviour.
The most well-known example of PHP's existing unsoundness is its treatment
of array keys, something that static analysis tools cannot detect:
https://psalm.dev/r/4640ef8f22 vs https://3v4l.org/XQTWc
Thread (8 messages)