How to fix or remove “Declaration of ... should be compatible with” errors that appeared with the transition to PHP 7

If you do not stick your head in the sand , that there are forces trying not to touch the old code that is still working, then there are a number of cases where corrections can be made either simply or doable. In the examples below, class B is a subclass of A The examples below will not necessarily eliminate fundamental violations of the principle of substitution (LSP), but at least PHP will not swear about them.

1. A special simple case is when the subclass method has a new argument that does not have a default value. Just add the default value and live on. Example:

    Declaration of B::foo() should be compatible with A::foo($bar = null) 

   You will do:

    - public function foo() + public function foo($bar = null) 

2. If restrictions are added to the subclass method, then they should be removed from the method signature, transferring to the function body.

    Declaration of B::add(Baz $baz) should be compatible with A::add($n) 

   You will want to use assert or throw an exception, depending on the severity of the error.

    - public function add(Baz $baz) + public function add($baz) { + assert($baz instanceof Baz); 

   If you see that the restrictions in the method signature are used only for documentation purposes, then transfer them to where the method parameters are documented, that is, in a comment.

    - protected function setValue(Baz $baz) + /** + * @param Baz $baz + */ + protected function setValue($baz) { + /** @var $baz Baz */ 

3. If there are fewer arguments in the subclass method than in the superclass, and you can make the arguments optional in the superclass, it will suffice to replace the unused arguments with stubs.

    Declaration of B::foo($param = '') should be compatible with A::foo($x = 40, $y = '') 

   You will do:

    - public function foo($param = '') + public function foo($param = '', $_ = null) 

4. If you see that some arguments in the subclass have become mandatory, remove the requirement of mandatoryness from the method signature in the method body.

    - protected function foo($bar) + protected function foo($bar = null) { + if (empty($bar['key'])) { + throw new Exception("Invalid argument"); + } 

5. Sometimes it may be easier to change the superclass method by removing the optional arguments, going to magic using func_get_args . Remember to document this virtual argument.

     /** + * @param callable $bar */ - public function getFoo($bar = false) + public function getFoo() { + if (func_num_args() && $bar = func_get_arg(0)) { + // go on with $bar 

   It is clear that removing more than one argument in this way can be difficult.

6. Everything is much more interesting if you have serious violations of the Liska principle. If your arguments do not require a type, everything is simple. It is enough to make all the arguments optional, then manually checking their presence. With this error:

    Declaration of B::save($key, $value) should be compatible with A::save($foo = NULL) 

   You will do:

    - public function save($key, $value) + public function save($key = null, $value = null) { + if (func_num_args() < 2) { + throw new Exception("Required argument missing"); + } 

   Note that we cannot use the func_get_args() function in this case because this function does not take arguments with default values. They simply will not be in the return value.

7. If you have a whole family of classes with a very different interface, it may make sense to change them even more. Rename the function that violates the substitution principle. Then add a proxy method to call a new, renamed method in a single subclass of the entire hierarchy of deviating classes.

    function save($arg = null) // соответствует родителю { $args = func_get_args(); return $this->saveExtra(...$args); // отличный интерфейс } 

   Thus, you do not eliminate the violation of the principle of substitution (new classes still cannot be called as if they are old), but you will keep all sorts of checks on the data types that are in the function signatures.