LSP (was Re: Function.prototype.bind)

Graydon Hoare graydon at
Wed Sep 10 15:55:36 PDT 2008

Mark S. Miller wrote:
> On Wed, Sep 10, 2008 at 12:49 AM, Brendan Eich <brendan at> wrote:
>> On Sep 9, 2008, at 11:51 PM, Mark S. Miller wrote:
>>>> LSP is not preserved by many cases in OO languages. Is it important here?
>>> I think it's a valuable property
>> It's come up before, but is it a sacred cow?
> Mu?
>> Method overriding in classical
>> OOP breaks it.
> How? I don't understand.

LSP is a formulation of subtyping, and it's one that few languages 
follow. This is (oddly) the second time it's been brought up on this 
list. It's really a bit of a non sequitur here, particularly since there 
is hardly anything resembling a type system in ES3 anyways. But for our 
edification (and to keep the term from re-emerging)...

Quoting Liskov[1]:

   "What is wanted here is something like the following substitution
    property: If for each object o1 of type S there is an object o2 of
    type T such that for all programs P defined in terms of T, the
    behavior of P is unchanged when o1 is substituted for o2, then S
    is a subtype of T."

Think it over. Imagine what you'd have to delete from any language you 
use, for its "subtype" relation to conform to that definition. Very few 
languages define "subtype" this way. It's somewhat supported via 
contract-based OO type systems (Eiffel, Sather and D, for example) in 
the sense that it holds for all and only the "behavior" you remembered 
to encode as a contract, and your contracts never fail; but in general 
as soon as you have behavior overriding (or first class functions at 
all) your subtype rule probably violates LSP.

(It'd be lovely if we all wrote in languages that treated subtypes this 
way; we'd have far fewer bugs. Wake me up when we get there!)



More information about the Es-discuss mailing list