Extended PHP class and public static methods with same name must have compatible signatures

Question

Just wondering why we have a E_STRICT/E_WARNING warning here:

class Node
{
    public static function create($parent = null)
    {
        // ...
    }
}

class NamedNode extends Node
{
    public static function create($name, $parent = null)
    {
        // ...
    }
}

As you can see in http://3v4l.org/n1s38, we have an E_STRICT (PHP < 7) or an E_WARNING (PHP ≥ 7). I really can't see any reason for this...

Furthermore, if we make the $name argument optional (http://3v4l.org/V1WHC), no warning is thrown... And that confuses me even more: if the method signatures must be the same (and as I said above I wonder why), why no warning is thrown?

EDIT: this is not a duplicate of Why is overriding method parameters a violation of strict standards in PHP? since here we are talking about static methods. I do think that non-static methods must have the same signature (since we'll work with instances in that case), but static methods are very different: we call the method statically, so we do know the class that get's called (eg Node::create() or NamedNode::create()).

possible duplicate of [Why is overriding method parameters a violation of strict standards in PHP?](http://stackoverflow.com/questions/13423494/why-is-overriding-method-parameters-a-violation-of-strict-standards-in-php) — pilsetnieks, May 19 '15 at 08:27
Because it violates best practice, and because I, as a programmer using your class library, don't want to have to know that methods in subclasses have different calling conventions from the same methods in the class they inherit from. — GordonM, May 19 '15 at 08:30
It's not a duplicated of http://stackoverflow.com/questions/13423494/why-is-overriding-method-parameters-a-violation-of-strict-standards-in-php since here we're talking about `static` methods. — Michele Locati, May 19 '15 at 08:36
@GordonM Do you have any reference for best practice that's applicable for this specific case (static methods)? — Michele Locati, May 19 '15 at 08:38
Look up the Liskov Substitution Principle, that's the best practice that's being violated here. — GordonM, May 19 '15 at 08:52
@GordonM I know it, but as I already wrote, we're talking about *static* methods... — Michele Locati, May 19 '15 at 08:57
@GordonM how do you even know this????? Something new learned everyday — The Humble Rat, May 19 '15 at 08:58
Anyone else interested in Liskov Substitution Principle, see here http://stackoverflow.com/questions/56860/what-is-the-liskov-substitution-principle — The Humble Rat, May 19 '15 at 09:04

Martijn Otto · Answer 1 · 2016-06-14T12:17:12.950

I can understand why making the name parameter optional would stop the warning from appearing. The Node::create function takes 0 or 1 parameters, of any type (since you did not use type hints). If you make the name parameter optional in NamedNode::create it accepts 0, 1 or 2 parameters, again of any type. This means that all valid call signatures for Node::create are also valid for NamedNode::create. You only add an extra possibility but that could not break old code.

Apparantly it is possible to call a static function on an instance, which is the reason that this warning is shown even for static functions. See also https://3v4l.org/FPEUj

Extended PHP class and public static methods with same name must have compatible signatures

1 Answers1