Re: Clean Object Class Design -- Circle/Ellipse

On Sun, 19 Aug 2001 21:19:11 -0400, "peter_douglass" wrote:

>Responding to Marc Gluch:
 ...
>>I would argue that it's a benefit of being in the subset relationship.
>>But what exactly is this benefit? The only one that I can see is
>>the ability to pass integers as arguments to real functions.
>>You get neither specification nor code reuse (average number of boxes
>>is code use, to get reuse you need to be able to compose
>>real functions with integer functions).
>Hmm. Integer and Real are different types, but using the same code for both
>is not code reuse. You apparently have a more restricted view of code reuse
>than I do.
Not necessarily. As an engineer, I do whatever gets the job done. However, in the context of discussing type inheritance (per title of Date's article), I am interested in seeing something more than what Fortran let me do 30 years ago.
>Can you give an example of this more restricted sort of code
>reuse?
I quoted a few times Smalltalk's Magnitude/Number hierarchy . Was that of any help?

>Let me ask you. Does a subtype, in your opinion, need to be a subclass?
The over way around. For me, (abstract) types are specifications, classes are implementations of these specifications.
>I ask this because the sense that I'm getting of your objection to Date/Badour
>is that Integer should not be a subtype of Rational because one typically
>constructs rationals from integers rather than the other way round.
That's just a tip of the iceberg.

> I would argue that subclassing and subtyping are orthogonal issues, which
>unfortunately have been merged in most OO languages.
Do you propose a separate mechamism (unrelated to inheritance) for declaring subtype relationship? For user-defined types, a simple declaration by itself is not enough. You actually have to give a prescription for upcasting/conversion. So you need to introduce a formalism for defining similarities between types (and for any two  sets there is plenty of ways to map elements of one to the other. are you going to define them all, or just these that you find useful in your app?).
Is your position that subset should be a formal concept (even though any set can be made a sebset of arbitrarily many newly created sets) and inheritance should be a hack for getting work done expediently, with no particular relationship to specifications? (Sorry if I sound extreme, I don't mean to put words in your mouth.  I appreciate the thoughtfulness that I always find in your posts).

>IMO, there is nothing wrong with using the specification of integers as a basis for the
>specification of rationals, yet make Integer as subtype of Rational.
That's where we disagree. IMO, everything is wrong with deriving integers from rationals (and, BTW, the other way around).
>Further, I think one should be able to declare a subtype relationship when
>there is no code inheritance one way or the other.
Why?

<snip>

>>>You don't seem to value sub-sets as being sub-types.
>>>I'm not sure why. For me, a key value
>>>of types is the ability to include specification information within a
>>>program, and to have the type-checker reject programs for which the
>>>included type specifications do not match the program functionality.
>>But what kind of specification are you talking about?
>>Signatures, or axiomatizations (invariants)?
>signatures
but declaration is not the same as specification. Any use of it (by the compiler) is superficial.

>>>Types used in this way are just useful decoration of programs,
>>> and may be erased without altering the semantics of the program,
>>>which could otherwise be written in an untyped language.
 

>Sorry you see little value in the compiler warning you that your
>declarations and usage don't match.
This is a different topic - manifest vs latent types. I started with Algol and Fortran. Then I spent 15 years writing in  Lisp, and 10 more writing in Smalltalk. For the last three years  I've been doing Java. I think I have tried enough of different languages to pass a judgement on which feature helps and which gets in my way. Obviously, this is just _my_ experience, but IMO if you have a design before jumping into coding, syntactic (compiler verifiable) type errors will be a rarity. Getting a grip on the semantics of the problem domain is a different story. You really need to nail down you axioms/invariants.
>However, others do, so your claim that
>declaring subsets as subtypes is useless is debatable.
My claim is relative to the current state of the art/technology/practice. Date's inheritance does not add any value to what's already available. It only confuses people by making distinction between values and variables, read and update operations. Variables are just names, placeholders for values. In pure Lisp (and other functional languages),  you don't need/use assignment.

I suspect that it's difficult for Date to come to terms with objects, because in the database world all values are immutable (don't change state). Neither do functions, until composed into recursive feedback loops. Out of a sudden you get values that change state -- Kay's "reactive engines".

Marc Gluch
Mindtap Inc. Received on Thu Aug 23 2001 - 05:52:45 CEST