Deklaracja metod powinna być zgodna z metodami nadrzędnymi w PHP

Ścisłe standardy: deklaracja childClass :: customMethod () powinna być zgodna z deklaracją parentClass :: customMethod ()

Jakie są możliwe przyczyny tego błędu w PHP? Gdzie mogę znaleźć informacje o tym, co to znaczy być kompatybilnym ?

childClass::customMethod()ma inne argumenty lub inny poziom dostępu (publiczny / prywatny / chroniony) niż parentClass::customMethod().

Ten komunikat oznacza, że ​​istnieją pewne możliwe wywołania metod, które mogą zakończyć się niepowodzeniem w czasie wykonywania. Załóżmy, że tak

class A { public function foo($a = 1) {;}}
class B extends A { public function foo($a) {;}}
function bar(A $a) {$a->foo();}

Kompilator sprawdza tylko wywołanie $ a-> foo () pod kątem wymagań A :: foo (), która nie wymaga żadnych parametrów. $ a może jednak być obiektem klasy B, który wymaga parametru, więc wywołanie zakończy się niepowodzeniem w czasie wykonywania.

To jednak nigdy nie może zawieść i nie powoduje błędu

class A { public function foo($a) {;}}
class B extends A { public function foo($a = 1) {;}}
function bar(A $a) {$a->foo();}

Zatem żadna metoda nie może mieć więcej wymaganych parametrów niż jej metoda nadrzędna.

Ta sama wiadomość jest również generowana, gdy wskazówki dotyczące typów nie pasują, ale w tym przypadku PHP jest jeszcze bardziej restrykcyjne. To daje błąd:

class A { public function foo(StdClass $a) {;}}
class B extends A { public function foo($a) {;}}

tak jak to:

class A { public function foo($a) {;}}
class B extends A { public function foo(StdClass $a) {;}}

Wydaje się, że jest to bardziej restrykcyjne niż powinno być i zakładam, że wynika to z przyczyn wewnętrznych.

Różnice w widoczności powodują inny błąd, ale z tego samego podstawowego powodu. Żadna metoda nie może być mniej widoczna niż jej metoda nadrzędna.

jeśli chcesz zachować formularz OOP bez wyłączania błędów, możesz również:

class A
{
    public function foo() {
        ;
    }
}
class B extends A
{
    /*instead of : 
    public function foo($a, $b, $c) {*/
    public function foo() {
        list($a, $b, $c) = func_get_args();
        // ...

    }
}

Aby rozwinąć ten błąd w kontekście interfejsu, jeśli wpisujesz wskazówki dotyczące parametrów funkcji w następujący sposób:

interfejs A

use Bar;

interface A
{
    public function foo(Bar $b);
}

Klasa B.

class B implements A
{
    public function foo(Bar $b);
}

Jeśli zapomniałeś dołączyć useinstrukcji do swojej klasy implementującej (Klasa B), otrzymasz również ten błąd, mimo że parametry metody są identyczne.

Napotkałem ten problem podczas próby rozszerzenia istniejącej klasy z GitHub. Spróbuję się wytłumaczyć, najpierw pisząc zajęcia tak, jak myślałem, że powinny, a potem zajęcia tak, jak jest teraz.

Co myślałem

namespace mycompany\CutreApi;

use mycompany\CutreApi\ClassOfVendor;

class CutreApi extends \vendor\AwesomeApi\AwesomeApi
{
   public function whatever(): ClassOfVendor
   {
        return new ClassOfVendor();
   }
}

Co w końcu zrobiłem

namespace mycompany\CutreApi;

use \vendor\AwesomeApi\ClassOfVendor;

class CutreApi extends \vendor\AwesomeApi\AwesomeApi
{
   public function whatever(): ClassOfVendor
   {
        return new \mycompany\CutreApi\ClassOfVendor();
   }
}

Wygląda więc na to, że ten błąd pojawia się również wtedy, gdy używasz metody zwracającej klasę z przestrzenią nazw i próbujesz zwrócić tę samą klasę, ale z inną przestrzenią nazw. Na szczęście znalazłem to rozwiązanie, ale nie do końca rozumiem korzyści płynące z tej funkcji w php 7.2, dla mnie normalne jest przepisywanie istniejących metod klas tak, jak ich potrzebujesz, w tym przedefiniowanie parametrów wejściowych i / lub nawet zachowanie metoda.

Jedną z wad poprzedniego podejścia jest to, że IDE nie mogły rozpoznać nowych metod zaimplementowanych w \ mycompany \ CutreApi \ ClassOfVendor (). Więc na razie pójdę z tą implementacją.

Obecnie zrobione

namespace mycompany\CutreApi;

use mycompany\CutreApi\ClassOfVendor;

class CutreApi extends \vendor\AwesomeApi\AwesomeApi
{
   public function getWhatever(): ClassOfVendor
   {
        return new ClassOfVendor();
   }
}

Więc zamiast próbować użyć metody „cokolwiek”, napisałem nową o nazwie „getWhthing”. W rzeczywistości obie robią to samo, po prostu zwracają klasę, ale z różnymi przestrzeniami nazw, jak opisałem wcześniej.

Mam nadzieję, że to może komuś pomóc.