Re: Clean Object Class Design -- Circle/Ellipse

On Tue, 14 Aug 2001 18:14:16 GMT, marc.gluch_at_mindtap.com (Marc Gluch) wrote:

>On Tue, 14 Aug 2001 12:25:07 GMT, dmitry_at_elros.cbb-automation.de
>(Dmitry Kazakov) wrote:
>
>>On 13 Aug 2001 07:49:08 -0700, marc.gluch_at_mindtap.com (Marc Gluch)
>>wrote:
>>
>>>dmitry_at_elros.cbb-automation.de (Dmitry Kazakov) wrote in message news:<3b739675.5091484_at_news.cis.dfn.de>...
>>>
>>>> Maybe LSP theory is more useful, but it does not explain the nature
>>>> phenomena. (:-)) Consider C++:
>>>>
>>>> 1. "const int" is what of "int"?
>>>constraint
 

>>If you mean that const is a constraint for int, then yes. And note
>>that applying a constraint to a type produces another type, which is
>>somehow related to the first. This relation can be called "to be a
>>subtype of".
 

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

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

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

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

>>>> 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 poit? Does Cobol have LSP-conform subtypes?

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

>>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? I am far more optimistic.

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

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

Regards,
Dmitry Kazakov Received on Wed Aug 15 2001 - 11:26:59 CEST