From: Sam Roberts <sroberts@...>
Date: 2005-05-29T03:44:53+09:00
Subject: Re: [ ruby-Patches-1939 ] Pathname, totally revamped

Wrote Mathieu Bouchard <matju@artengine.ca>, on Tue, May 24, 2005 at 11:28:28AM +0900:
> On Tue, 24 May 2005, Sam Roberts wrote:
> >Sometimes called Liskov substitution principle.
> >>never override any method in a subclass, because hey, people might not
> >>expect different behavior.
> >You derive to override implementation, not behaviour.
> 
> So, in short, Liskov's substitution principle can be written:
> 
>   (SubPre -> SubPost) -> (SuperPre -> SuperPost)
> 
> again as a logical implication.
> 
> Does that sound accurate?

Uhm, well, IMHO, thats so abstract its hard to know if its accurate,
maybe it could be argued both ways. :-)

My understanding is that Liskov means:

  If you have a program using an X, and Y is-a X, then you can use Y
  instead of X and it will "work", for some definition of work...

Thats kindof vague, but the idea is pretty clear. You can make a class
that is attached to a string in a DB record, or  that encapsulates the
data in a file, or uses the Boehm rope data structure, or ..., and if
you can use them in an API that expects a String, and it works, then
they are Liskov substituteable for a String.

Pragmatically, its likely that any particular implementation may work in
some cases, but not in others... If it's a read-only file, any attempt
at doing a desctructive operation is going to fail, and code that
assumes that a String that is not frozen is modifiable will find that
this hypothetical file-as-String class is not Liskov substitutable for a
String.

Design is still partially a matter of taste, not exact rules, isn't it?

Cheers,
Sam