LSP (was Re: Function.prototype.bind)

Mark S. Miller erights at
Wed Sep 10 16:09:45 PDT 2008

On Wed, Sep 10, 2008 at 3:55 PM, Graydon Hoare <graydon at> wrote:
> Mark S. Miller wrote:
>> On Wed, Sep 10, 2008 at 12:49 AM, Brendan Eich <brendan at> wrote:
>>> Method overriding in classical
>>> OOP breaks [LSP].
>> 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. [...]

I see. Thanks for the clarification. I had not understood LSP as a
property for a language to enforce, but rather as a design rule for
programmers. Nominal types usually correspond to some behavioral
expectations -- a contract if you will -- that are used to coordinate
the expectations of implementers of a type and clients of a type.
However, these contracts are rarely written down, and hardly ever
written down in machine understandable form. So I agree that enforced
LSP is unrealistic, because one can't enforce conformance to
expectations that aren't written down. But, as a programmer, one can
endeavor to only claim that an X is a kind of Y when X satisfies all
the expectations that clients of Y expect. If this isn't LSP, it is at
least design by contract with nominal types as contract names. It is
still a good design rule in languages (like JavaScript) with nominal
subtyping (via instanceof).


More information about the Es-discuss mailing list