Re: Clean Object Class Design -- Circle/Ellipse

"peter_douglass" <baisly_at_gis.net> wrote in message news:3b856b15_at_tobjects.newsource.com...
>
> 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.

I'm having the same problem.

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

It is. Peter, having used Smalltalk in heavy numerical methods work, having extended the class hierarchy to Infinity, Complex, Vector, Matrix, Function, Integral, Derivative, Polynomial, and a few other things I cannot even remember, I'm
convinced it is a wonderfully powerful hierarchy and has *implemented* math "right", *practically* (loaded and context-specific term, of course) speaking.
The common stuff for all "numbers" is abstracted out to a Number class, and Integer and Real derive from it. Fractions are Number subclasses
for Rationals. (you're on your own for irrationals, but even this is possible:-)
The only thing I really needed to do was create a new abstract class in between
Number and its superclass, because there are things that are mathy but not numbers, e.g, a Function. I called this abstract class "NumericalThingy". (Almost) seriously :-)

Note: The folks who do the more abstract math will quibble with me as they have another hierarchy they need to deal with (e.g., the group of curves, and whatever rings are :-)

Shoot. Having written this, I see I've fallen prey to ye old empty dogmatism.

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

A Smalltalker is going to be more pragmatic that this. We'd probably agree with you, then go back to using our "known violations" for convenience. Smalltalk is a comfortable "womb" that lets us do "bad" things but makes it so convenient. . .perhaps a lotus leaf and not a womb :-?
Nah, we can get ourselves out of trouble too easily :-)

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

Defer to Marc for this one.

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

Oops. Ok, take a look at the Smalltalk Number class hierarchy, but better not use Smalltalk . .you are not a "chosen one" :-)))

[snip]
>
> >Do you propose a separate mechamism (unrelated to inheritance)
> >for declaring subtype relationship?
>
> Yes.

AFAIK, it has to be. No one has been able to put the two together.

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

Ok, but if you try and *subclass* Integer from Rational, inspection of the result will convince you to toss it into the trash. Different thing.

> >>Further, I think one should be able to declare a subtype relationship
 when
> >>there is no code inheritance one way or the other.
 

> >Why?

Marc asked this to elucidate Peter's ideas. Since he uses Smalltalk, he is well aware of the benefit of common type hierarchies where there is no code/inheritance relationship whatsoever.

>
> 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. Similarly,
> Rational would probablynot be a subclass of Integer, although its
> declaration may have a dependency upon Integer. It would be nice to be
 able
> to declare Integer a subtype of Rational.

And it should be, imho. Just not subclassed. Do you think the subclass/subtype confusions have a similarity to the value/variable ? Received on Fri Aug 24 2001 - 08:04:36 CEST