Does it make sense to remove slots ?

[Tim Moore]

On Nov 7, 2004, at 4:56 PM, Massimo Dentico wrote:

> "Tim Moore" <Timothy at Moore.name> wrote:
>
>> That's a pretty well-accepted object oriented design philosophy known  
>> as Liskov's Substitution Principle. It's actually often phrased in  
>> terms of "the circle/elipse problem" as a matter of fact.
>> Check out  
>> http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq 
>> -21.6
>> which as you can see is in a C++ FAQ, but really applies to object  
>> oriented design in general.
>> Also see http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple for some  
>> extended discussion.
>
> Oh.. the sacred dogma, the "Liskov's Substitution Principle".
> Unfortunately for the followers some non-followers exist, see
> "WHAT DOES SUBSTITUTABILITY REALLY MEAN?", by Chris Date:
>
>  http://www.dbdebunk.com/page/page/626998.htm

I don't know about "sacred dogma" but I would say that it is generally  
a good idea.

>> Long story short: Todd is right. Circle shouldn't be derived from  
>> Ellipse unless they're both immutable, and most likely you don't  
>> really need a Circle type at all.
>
> Please, explain what does it mean to mutate a *value*.
>
> A *value* is immutable by definition; what you can mutate
> eventually is a *variable*. In the context of a prototype-based
> languages as Slate, slots are variables.

I'm sorry, but I don't really understand what you're getting at. What  
I'm saying is that if Circle and Ellipse are immutable (i.e., the slots  
don't change after construction and the whole object acts as a  
conceptual value) then there are no problems. However if you do allow  
the axis lengths to change (i.e., the classes function as variables)  
then you can run into problems.

> Besides this, I agree with Peter van Rooijen: if you decouple
> the concept of inheritance/subclassing from that of subtyping
> (IIRC as in Sather http://www.icsi.berkeley.edu/~sather/) the
> problems vanishes:
>
> - subtyping means:  if A is a subtype of B, then A is a subset of B;
> - inheriting means: if A inherit from B, then part/all of the structure
>                    and/or behavior of B is *included* in (inherited  
> by) A.

How would that apply here?
-- 
Tim Moore