Martin Snelgrove <snelgar <at> dissonance.com> writes:
 
> I'm happy enough to accept the advice that Complex isn't Point, which makes
>sense enough to me.

Phew.  Thanks!  I notice that Stef pointed out for the record that Complex is a
point, which I accept mathematically --- I just don't believe it is-a Point
Smalltalk-wise.

> What seems wrong to me about the current implementation is that (1 + 3i)
>isNumber -> false, and that seems wrong

I agree, but I think you have already touched on this, in terms of Number being
a Magnitude.    So a Complex is a number in maths, but it you can't say it is-a
Number in the class sense.

> The author of Complex notes in horror (see the class comment) that he had to
> cut-and-paste a number of methods from Number, including abs, negated, ...

So how about we interpose 'ArithmeticalEntity' as a new parent?  All those
methods that had to be copied from Number to Complex could just be moved from
Number up to this new parent.  An ArithmeticalEntity (I'm sure we can come up
with a better name) is something that you can do arithmetic with, but which is
not a magnitude --- and therefore '<' and '>' will not work.  It's probably the
subclass from which vectors and matrices can be derived --- you can multiply
them (sometimes), negate them, and test for equality, but you can't decide which
is bigger.

So I've got no problem with Complex as a sibling of Point --- in fact that's
where I think it belongs.  But a number of people have knowingly mentioned
Traits: can one of you please elucidate --- I'm struggling with these concepts
at the moment, due to career "progression": all my previous Smalltalk expertise
(such as it was) has been replaced with shaking hands, and making Excel models
(and Powerpoint presentations) over the last five years, to the point I feel I
know very little of real worth.

... John