Re: Clean Object Class Design -- Circle/Ellipse

dmitry_at_elros.cbb-automation.de (Dmitry Kazakov) wrote in message news:<3b7a3110.3341281_at_news.cis.dfn.de>...

> >that depends on the definition of subtype.
> >if you take type = set, there is no need for type and subtype,
> >we already have set and subset.
>
> Surely type is a set. But what you meant (I suppose) is that type is
> not the domain set. That's true, usually it is said that type is a set
> of values (domain) + set of operations.
Which is an algebraic structure with properties very different from the properties of the set of (domain) values. Equating the two leads to confusion.

> >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. Try search on "Inheritance is not 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).  

>>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.

>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.  

> >>>> What should we correct, the nature or the theory? (:-))
> >>>Since when is C++ (equivalent to) the nature?
> >>Since its appearance (:-)). One could argue that not all is wonderful
> >>in our wonderful world, but there is no other. And this is not only
> >>C++ fault. I used C++ because it is known to all.
> >Poor assumption -- plenty of counterexamples in the Cobol world.
> 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. 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.

> >>In Ada: subtype NumberOfDiskHeads is Integer range 1..16;
> >>subtype CommandLine is String (1..80);
> >>Neither above is a LSP subtype. So there is a phenomenon: one can
> >>specialize types, but the result is not LSP conform.
> >That depends on the type definition adopted by each language.
> No whether something is a LSP subtype or not does not depend on what a
> particular language calls "type".
I meant that whether a subtype (as defined) in a languge is a LSP subtype depends on a language. I'd like to think (but don't know) that CLU may be an example of a language where subtype == LSP subtype.

> >>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.

> >The definitions traditionally provided in programming
> >languages are mildly useful, and even instrict languages
> >they are made *optional* by availability of *cast*.
>
> 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.

> >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. Inheritance is one of (many) possibilities. I prefer to view inheritance as a different dimension of the design space.

Marc Gluch
Mindtap Inc. Received on Wed Aug 15 2001 - 18:42:41 CEST