Re: Clean Object Class Design -- Circle/Ellipse
Date: Tue, 14 Aug 2001 18:14:16 GMT
Message-ID: <3b7961dc.3366926644_at_news.grpvine1.tx.home.com>
>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.
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
>>> 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).
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.
>Moreover, to have an implicit conversion from int to double
>(to me it is what "to be a subtype" means), one should additionally
>make double a supertype of Number, so that int->Number->double
>conversion path could exist. This makes int a subtype of double.
>
>>> 3. "float" is what of "double"?
>>cousin
>>
>>> 4. "int [23]" is what of "int *"?
>>int[23] is an instance on int[].
>
>I meant types:
>
>int X [23];
>int * Y;
>
>>Would have to examine the specs of int array and int pointer
>>to determine how their axiomatizations relate.
>
>One is an unconstrained array another is a constrained one. It means
>that Y [150] is valid, X [150] is invalid.
Per your explanations of C, neither one is a (Liskov) subtype of the
other. In Smalltalk Array is a subtype of Collection.
int[23] (in a different syntax) would be an instance of Array.
>>> Is there a language where for any two related types, one is a
>>> LSP-subtype of another?
>>Language has little to do with it (other than built in types).
>>It's up to you how you use it (you define your abstractions).
>>
>>> 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.
>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.
>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.
The definitions traditionally provided in programming
languages are mildly useful, and even instrict languages
they are made *optional* by availability of *cast*.
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.
Marc Gluch
Mindtap inc.
Received on Tue Aug 14 2001 - 20:14:16 CEST