Protected inheritance hierarchies

I'm not sure that this is a bug. You can redeclare the same type and
add
hooks (or change them), which breaks all assumptions about
substitutability.

Rob, maybe you can lecture me a bit: Isn't substitutability on the
public
interface / protocol only? What am I not seeing in your example?

From a child class's perspective, the "public interface" is both
protected + public of the parent. If you change or misuse a parent's
implementation or invariants, it violates LSP, even if it doesn't affect
external clients immediately.

Ah okay, that part is not in my book, this explains to me why in your
example it violates substitutability for you, and with that thinking it
also prevents or degrades implementability for me so to say, as otherwise I
could not make use of visibility in classes - it would take away that tool
from me or I would not treat it well, potentially leading to defects in the
program.

See my reply to Jonathan. But you are free to dismiss LSP when needed. There are a lot of times when LSP isn’t the right design constraint (which I briefly mention in that email), for example, during larger migration/refactors, specialized proxies, caching results, etc., or even using sibling classes as friend classes.

PHP doesn’t strictly enforce LSP everywhere. It will get out of your way when you need it to. It’s your code, you can do whatever you want with it.

Even when I see an LSP violation at work (rare, but it happens), I don’t point it out as such, but instead point out why the approach is a bad idea (maintainability, principle of least surprise, etc). If they do it continuously, then I might have to invest in some coaching for the dev, but mostly, people don’t violate LSP for the more obvious reasons, and when they do, they usually have good reasons (see above).

Thanks a lot for sharing your thoughts that openly and briefly, much appreceated.

This all sounds rather sane to me, given PHP is not a design by contract language and what makes LSP stand out from formal type theory can get easily lost then, especially when applied with force.

I've also studied your other reply to Jonathan.

Take for example:

class Fruit {
public string $kind { get => "fruit" }
}

class Vegetable extends Fruit {
public string $kind { get => "vegetable" }
}

function foo(Fruit $fruit) {}

foo(new Vegetable); // hmmm

This is a "soft" violation that only makes sense to us humans, but PHP
allows it. It requires us humans to realize we are performing an LSP
violation and refactor the code so that we don't pass a Carrot to someone
expecting a Mango.

Thankfully in this example it is all public, but I definitely would say
this is not an LSP violation, just saying.

This can be done through protected means as well (simply replace the
properties above as protected properties used internally), and it won't be
as obvious to consumers outside the class, but still there, nonetheless.

Okay, this is it probably just like above (for me): When $kind would be
protected, it would not be part of the public protocol, and the
substitutability test with the PHP runtime would still pass for the
foo(Fruit) event with a Vegetable that is a Fruit (extends). That would be
a test for substitutability, per the PHP runtime guarantees (it returns
successfully after sending the message), it does not break the program:

an object (such as a class) may be replaced by a sub-object (such as a
class that extends the first class) without breaking the program. (WP LSP)
<<

Still trying to learn more, though.

Let me guess: The following hierarchy is not substitutable for you, as we
can still pass Vegetable for Fruit on foo()'s protocol. Is that correct?

 class Fruit {
     // intentionally left blank
 }

 class Vegetable extends Fruit {
     // intentionally left blank
 }

 function foo(Fruit $fruit) {}

 foo(new Vegetable); // hmmm

-- hakre

I don’t see any reason why this example would violate LSP. There is no discernible difference between the two classes. LSP only says they are substituable in regards to type, and behaviour, and an empty class is probably only a sentinel value, in which case the behaviour is external to the type. I might have an issue with saying a vegetable is a fruit, but that is a naming issue… and naming is hard.

So by protocol, this settled a bit more in harmony. Fine.

And while naming is hard, names are harder: Given that LSP, PHP and the (earlier with hooks) class definitions are all human made, and furthermore that fruits and vegetables grow from nature, there is or was at least one local jurisdiction that would have needed them in their program exactly that way: a vegetable declared Fruit. A delicious example of sub-typing refreshingly POLArizing.

Thanks Rob.

-- hakre

From a child class's perspective, the "public interface" is both
protected + public of the parent. If you change or misuse a parent's
implementation or invariants, it violates LSP, even if it doesn't affect
external clients immediately.

Ah okay, that part is not in my book, this explains to me why in your
example it violates substitutability for you, and with that thinking it
also prevents or degrades implementability for me so to say, as
otherwise I could not make use of visibility in classes - it would take
away that tool from me or I would not treat it well, potentially leading
to defects in the program.

Don't believe everything you read on the internet.

If you weren't allowed to change a parent's implementation, then you
wouldn't be permitted to override methods at all, at which point
inheritance is pointless.

It's funny that he's starting to talk about invariants here. Seems he
doesn't realize every example he's given so far is covariant (Besides
the one at the beginning of the thread where he confused static and
non-static properties)

He's trying to argue that LSP is about implementation when it's not.
This is an interface with a function signature:

interface I {
function f(): string;
}

See a fruit anywhere? Me neither. That's because there isn't one. It's
not part of the signature. It's not part of the interface. It's not part
of the definition. It's not part of the contract.

This is a class with the same function signature:

class C {
function f(): string {
return "fruit";
}
}

In fact, this class could implement that interface without any problems,
because the signature is identical. The types are identical. There is no
LSP violation. There is also no contract that implies C::f() returns
"fruit".

If you made that assumption I'd call it a lack of error handling from
someone who only considered the happy path. Static analysis tools exist
to stop you from making these mistakes.

Once more, just to drive the point home. This is an interface with a
function signature:

interface I {
public int $p { get; }
}

This is a class with the same function signature (And one more for good
measure, because I::$p is covariant!):

class C {
public int $p;
}

In fact, this class could implement that interface without any problems,
because the signature is identical. The types are identical. There is no
LSP violation. There is no contract that implies that getting C->p will
return a certain value, other than that the value will be an int.

---

Back to the original issue: I'm going to open a github issue on this
since it's clearly a bug and I don't see fixing it breaking any existing
code.

Hey Jonathan:

It seems we’re talking past each other a bit, so let me clarify.

Liskov’s original work (which is worth reading, since it seems you haven’t) frames LSP as a behavioural contract, not merely a type signature. When the principle was introduced in the 1980s, modern type systems barely existed—the focus was always on whether substituting a child for a parent would break expected behaviour, not just the surface-level types.

For example, if A::foo(): int promises to always return a non-zero integer, and a subclass overrides foo() to only return zero, that violates the contract—even though the type signatures match perfectly. This is the sort of semantic guarantee that LSP is about, and it is discussed in nearly every reputable textbook and conference talk on OO design. Languages like PHP can’t enforce these contracts, but the principle is what helps prevent subtle design bugs and behavioural “surprises.”

You mention that overriding methods is the point of inheritance. Of course! That is where LSP matters most. It is about ensuring that overriding methods (and properties) in subclasses don’t break expectations encoded or implied in the parent.

On invariants: These are a textbook part of LSP. The values and guarantees behind properties (not just their types) are what client code may rely on. That is why invariants are so often referenced in the LSP context.

As for your example with interfaces and signatures: Yes, two signatures can match perfectly, and yet LSP can still be violated if the contract (explicit or implicit) is not honoured. Static analysis tools can help, but they only go so far—they can’t check for semantic compatibility.

So while a language or type system may permit something, that doesn’t mean it’s a good idea from a design or maintainability perspective.

Looking forward to your GitHub issue.

— Rob

Le 7 août 2025 à 20:37, Jonathan Vollebregt jnv@jnvsor.net a écrit :

Back to the original issue: I'm going to open a github issue on this since it's clearly a bug and I don't see fixing it breaking any existing code.

Hi,

Sorry to reply without completely reading this long thread.

As many of us understand it, the application of Liskov Substitution Principle indeed shows that, if you can access a member declared in a given class from a given context, you ought also be able to access the same member when it is redeclared in a subclass.

This is true whether the member is concretly a method, a property or a constant, or whether it is static or not.

I am writing this to draw the attention that the issue should be resolved not only for protected properties, but also for protected constants.

Test cases currently passed:

protected method: https://3v4l.org/LmLLu
protected static method: https://3v4l.org/vjllN

Test cases currently in failure:

protected property: https://3v4l.org/br0tj
protected static property: https://3v4l.org/2Ue97
protected constant: https://3v4l.org/jXm6U

—Claude