Strict standards versus fatal error / concrete extension versus abstract implementation
I've noticed that PHP behaves differently depending on whether the class subclasses the concrete base class or implements the method or interface of the abstract base class with respect to homogeneity in the method signatures. Consider these two examples
//----------------------------
// Strict Error
//----------------------------
class C { function blah(ArrayAccess $a) {} }
class D extends C { function blah($a) {} } // <- No type-hint in subclass method
//----------------------------
// Fatal Error
//----------------------------
interface A { function blah(ArrayAccess $a); }
class B implements A { function blah($a) {} } // <- No type-hint in subclass method
Here's the output
Strict standards: Declaration D :: blah () must be compliant with C :: blah (ArrayAccess $ a) PHP Fatal error: Declaration B :: blah () must be compliant with A :: blah (ArrayAccess $ a)
My question . Why would PHP be able to view these two scenarios differently, perhaps for historical reasons? I seem to like the same problem.
I assume that you can avoid this in a specific case, since the subclass should not call the parent class's implementation in its implementation. Anyway, I'm still curious.
source to share
I don't have formal words to explain the difference, but this is how I see things.
An interface is a public implementation contract. As a contract, you must follow the rules defined in the interface. Without following them, break the contract to make a fatal mistake.
Extending a class can define its own rules. These rules should be similar to the base class, otherwise things get a little weird when you change the implementation to a different one. But if the rules are different, but the implementation handles correctly, this is "just" a severe error.
source to share