LSP (was Re: Function.prototype.bind)
graydon at mozilla.com
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 mozilla.org> 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?
>> 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)...
"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