Re: Clean Object Class Design -- Circle/Ellipse

On 15 Aug 2001 09:42:41 -0700, marc.gluch_at_mindtap.com (Marc Gluch) wrote:

>Which is an algebraic structure with properties very different
>from the properties of the set of (domain) values.
>Equating the two leads to confusion.

So far I followed the discussion about LSP, nobody equated them.

>> >if you take Liskov's definition of abstract ype
>> >then not every constraint produces a subtype,
>> >only these that are consistent with the original axiomatization
>> But that black sheeps produce something usable. This is my point.
>> There is a phenomenon and the theory does not explain it.
>The black sheep are not black. In fact they are not sheep. They are cows.
>They produce milk, just as sheep do, but that does not make them sheep.

Call they mammals.

>Try search on "Inheritance is not subtyping".

Inheritance is the carrier of subtyping.

>> >>>> 2. "int" is what of "double"?
>> >>>cousin -- both are (concrete) subtypes of (implicit in C++) Number
>> >>Well, then int is a subtype of that Number and it is not a LSP subtype.
>> >What makes you think so? C does not define Number type per se (AFAIK).
>> You said that Number is implicit. My point is, it is no matter whether
>> int is a direct subtype (or what else) of double or an indirect one.
>I said that int and double are not in a relationship of subtype ordering.
>They both are realizations of different subsets of Numbers (parallel paths).
>Int is a subtype of Number (or you can think of int as an instance
>(concrete type) of the abstract type Number (with set of inhabitants <- I).

This does not explain why 1 + 2.0 is legal in C++.

>>>In Smalltalk Integer is a subclass of Number (as are other concrete
>>>implementations of subalgebras of Number such as Fraction and Float),
>>>and you can use all functions defined in Number on integers.
>> Call it subclass if you want [however I see no reason to introduce the
>> term "subclass" in addition to "subtype"].
>There is a reason; subclass =/= subtype.

So what? Consider the phenomenon: SUBBISM = { x | x is a subclass or x is a LSP subtype }. How do you call SUBBISM?

>>The question is, whether a reasonably defined Integer can be a LSP-subtype
>>of a reasonable defined Number in a language X?
>>I know plenty languages where it isn't so.
>Such as? I kind of doubt there are many languages that go through the trouble
>of explicitly defining the type Number but are not concerned about LSP.

Maybe they express concern (:-)), but they can do nothing about the source of it: not all algorithms working for the set of complex numbers work for integers too.

>> Sorry, what is the point? Does Cobol have LSP-conform subtypes?
>The point is that we are talking about concepts that transcendent
>many different languages. No language is a faithfull model of reality.

Here I must disagree. Language is the reality. Period.

>They all are approximations. C++ is a lousy reference point to pick.
>Try Scheme, ML, or Haskell. At least they abstract away from the
>physics of hardware.

I do not see how notions of constraint, lazy computation, concurrent access etc are related to the hardware. Then even if some language construct is related to the hardware, like placement or representation specifications, then [provided that the hardware should be programmed, somehow (:-))], I would like to have a subtype theory that deals with that disgustful hardware. It is very easy to say that a language X is cripple (which is true regarding C++), and therefore there is no problem with LSP subtyping.

>> >>The question is, do we want to have specialized
>> >>(and generalized) types or only LSP ones?
>> >It depends on what use you want to make of the type definition.
>> So in your opinion the situation is so bad, that each time one need to
>> write a program he/she should invent an appropriate type definition?
>There is no need for that. Just stop confusing subtype and subclass.
>Subtype is a specification level construct.
>Subclass is at the implementation level.

1. Let it be so. How does it help?
2. I agree that "subtype is a specification level construct". So subtype Positive is Integer range 1..Integer'Last; is a subtype and it is not a LSP one. Now there are two possibilities: either (A) nobody needs the type Positive or (B) LSP notion of subtype is not complete. A is false - there is me who needs the type Positive (:-)). q.e.d.

>> How should definitions look like in a dream language? Again the
>> question is, is "be a LSP subtype" the only necessary type relation or
>> not. If the answer is yes, then we indeed do not need all that const,
>> volatile, atomic, lazy, contrained etc.
>In my dream language types don't "look" .
>The compiler derives them, instead of forcing me to declare them.

Should it mean that all types be derived from untyped values? It cannot be done. A theory that deals with types cannot be derived in the theory of the values of those types. Problems with LSP just highlight that.

>> >My preference is to stick to the type/subtype definition adopted in
>> >math (and Liskov's definition does that) and use other constructs
>> >(say composition and inheritance) for nonconforming constructions.
>> Dare I interpret the above as "LSP inheritance is not all inheritance
>> and LSP subtype is not any subtype"? Then it means that LSP notion of
>> subtype does not cover all interesting (to many) cases. That was
>> exactly my point.
>subtype = subset and subtype = LSP are two (opposite) ends of a spectrum
>of possible and usable type definitions.

1. I believe that LSP subtype [in its original form] can be made "domain subset" by an appropriate definition of the set of properties that the derived type should preserve.
2. The requirement that the subtype domain be a subset of the base type domain, i.e. [in ADT] there is a mapping g:S->T that s1/=s2 => g(s1)/=g(s2), this requirement is too strong to me, because it excludes type generalization.

>Inheritance is one of (many) possibilities.
>I prefer to view inheritance as a different dimension of the design space.

IMO Inheritance is just a view on subtyping. If S inherits something from T, S is a subtype of T.

Regards,
Dmitry Kazakov Received on Thu Aug 16 2001 - 10:42:32 CEST