Re: Clean Object Class Design -- Circle/Ellipse
Date: Mon, 27 Aug 2001 07:00:51 GMT
Message-ID: <3b897b99.3708242_at_news.grpvine1.tx.home.com>
On Thu, 23 Aug 2001 21:33:51 -0400, "peter_douglass" <baisly_at_gis.net> wrote:
>I went back and re-read your posts, and I must confess that I am still quite
>confused. Much of the confusion has nothing to do with how you use the term
>"code re-use", but since the reference to your posts his here, I will raise
>my concerns here. In some posts you make a big fuss about the closure of
>operations and how the multiplicative inverse is not closed over integers.
>Yet one of the defining operations of Magnitude is "<", which in most
>languages returns a boolean value, not another magnitude. Thus, the fuss
>you make regarding the closure of operations over a type seems inconsistant.
An abstract algebra is defined as a triplet A = <V, O, R>
V - set of values (constants) O - set of operations (functions) R - set of relations
You can get rid of values by treating them as functions (with arity of 0).
You can get rid of relations by treating them as characteristic functions: V^n -> {true, false}
Now we can say that A = <O'>, where O' = O +V + R Note that every type (per Martin-Lof def) must have equality among its primitive functions (operators).
> You will need to educate me regarding Smalltalk, as I don't know if there
>are instances of Magnitude which are not also instances of subclasses, i.e.
>I don't know if Magnitude is an abstract class.
Yes, it is.
>If your point is that
>subtyping from concrete classes is less useful or elegant than subtyping
>from abstract classes, then I would probably agree with you.
Even more importantly -- unsafe (when violating LSP).
> It is perhaps from this perspective that you so vehemently object to the notion of
>defining circle to be a subtype of ellipse or rational a subtype of real.
No (at least not primarily). Elegance and utility are important, but
my pimary objective is that a subtheory be consistent with its
supertheory (thus satisfying LSP). If the axiomatizations are
inconsistent, there is no point in subtyping.
>In my C++ programming I avoid inheritance from concrete classes except when
>my philosophical position threatens to interfere with my ability to work
>with my peers.
or threatens project timeline or budget. Both of us are pragmatic.
>So I will ask you if your point is that subtype inheritance
>should only be from abstract classes?
I don't go that far. I only ask for consistency (though typically that
precludes inheriting from a concrete class.
>>> (...)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.
>Elaborate all you care to.
My objection to Date is on several grounds:
a) "read only" inheritance b) values vs variables c) denial of objects -- We find no need to drag in any kind of"object" concept at all
d) presumption that there is only one right way (his) to construct models -- In the real world, every ellipse has a "major semiaxis" of length a and a "minor semiaxis" of length b (and we can assume without loss of generality that a >= b). A circle, then, is precisely an ellipse for which a = b (for a circle, in fact, the two semiaxes coincide in the radius). In the real world, therefore, there can surely be no argument that a circle categorically is an ellipse (or, rather, a circle is a special case of an ellipse).
>>> I would argue that subclassing and subtyping are orthogonal issues, which
>>>unfortunately have been merged in most OO languages.
>Yes, inheritance from a concrete class should not (necessarily) generate a
>subtype relationship. In this regard, I highly recommend:
>Subtyping is not a good ``Match'' for object-oriented languages
>Typing in OO languages: Achieving expressiveness and safety
>PolyTOIL: A type-safe polymorphic object-oriented language
>and as background to the above
>On binary methods, by Kim B. Bruce, Luca Cardelli, Giuseppe Castagna, The
>Hopkins Objects Group, Gary T. Leavens, and Benjamin Pierce.
>the authors argue for separate mechanisms for subtyping and subclassing
>so that code can be re-used without running into well known problems
>where a subclass violates LSP.
Even these authors don't claim that subtyping and subclassing are
orthogonal ("Unfortunately, the relations of matching and subtyping
are similar enough that it might be difficult for a programmer to keep
their differences straight" from the first reference)
The breakit example in "On binary methods" is bogus. In Smalltalk you learn very quickly that any definition of =(x, y) has to have a =(type(x), type(y)) component. ColoredPoint is not a subtype of Point in their example only because of their choice of definiton for the subtype relationship (contravariance).
On the other hand, I'll grant you that inheritance (as defined in most programming languages) has dubious semantics - you can make a subclass to be a specialization or a generalization of its superclass and the compiler doesn't care.
>I don't propose that integers be "derived" from rationals, nor do I think
>that is Date's proposal. One starts with integers, "derives" rationals,
>then declares that, by the way, integers are rationals too, so any function
>that takes rational values as arguments will work if I pass in an integer
>value.
a) integers are not rationals. If you pass a "raw" integer to a
rational function, you'll get an error. You have to convert the
integer to rational (or get the compiler to do it for you), for the
rational function to work.
b) in your derivation, how do integers inherit properties of rationals
(Date - "To use the jargon, we say that ELLIPSE and CIRCLE are
supertype and subtype, respectively, and we say that the subtype
inherits properties from the supertype")?
>>>Further, I think one should be able to declare a subtype relationship when
>>>there is no code inheritance one way or the other.
>>Why?
>Because although the definition of rational is likely to use integers, it is
>likely to not be a subclass. Look again at Magnitude and Boolean. The
>definition of Magnitude requires the presence of a definition of Boolean.
>This doesn't mean that Magnitude is a subclass of Boolean.
Addressed up front (top?) -- predicates vs terms.
A type can have some (characteristic) functions describing
relationships (predicates) among instances of the type
(equality in particular)
Functions that build terms must be closed in the type.
Composite types introduce another kind of signature
Type -> ComponentType
(so I can ask a circle about its radius)
> If you have worked out the axioms,(contracts?)
>how do you ensure that clients of your code (perhaps written by
>other developers) observe your axioms (contracts)?
You give them the specs/contract. It's their responsibility to
conform.
>(...) there is division within the database world. On the one
>hand there are relationists like Date, there are incorrectly implemented
>"relational" products, and there are non-relational OO products. Date
>stresses the importance of the value/variable distinction because others
>neglect that distinction which IMHO leads to confused thinking.
I don't have a problem woith Date clarifying confusion in the db
world. The problem is creation of confusion in the programming world
and his "solution" -- read-nly inheritance.
>> Neither do functions, until composed into
>>recursive feedback loops. Out of a sudden you get values
>>that change state -- Kay's "reactive engines".
>Functions are still immutable even if they are part of recursive feedback
>loops.
I'll start a new thread -- Mutable Values.
Marc Gluch
Mindtap Inc.
Received on Mon Aug 27 2001 - 09:00:51 CEST