Martin Snelgrove <snelgar <at> dissonance.com> writes:

> I had also wondered about building Complex out of Point.

IMHO: PLEASE don't do this.  

Point was primarily conceived, afaik, as something to be used in a graphical
context --- think of the use of Point to create Rectangles, for instance.  It is
nice to be able to plot complex numbers on the 2D plane, but that doesn't seem
sufficient motive for messing up (again im*H*o)the class hierarchy, and
confusing graphical elements with arithmetical ones.

I would accept that Point and Complex could share an ancestor (interposing
something like, say, 'ArithmeticalValue' between Object and Point) but I feel
that the only reason Complex looks like a child of Point is that it has two
components --- but then, so does Association!

Rather I would suggest that you create a method 'i' on Number which returns:

^Complex new
  realPart: self class zero imaginary part 
  imaginaryPart: self

Then make sure a complex prints (and stores) itself out as (a + bi).  When you
evaluate that expression, it will actually work, so you can write (once you've
implemented Complex>>*) (1 + 2i) * (3 + 4i) and everything will be fine.  This
looks more like doing complex number math than (1 at 2) * (3 at 4).  Perhaps more
importantly, if you inspect the latter, you will get (3 at 8) because, true to its
graphical origins, Point interprets '*' to mean scaling, and where the argument
is also a point it scales self x by new x and self y by new y.  The answer we
were looking for, of course, was (-5 + 10i).

So my view is that Complex is not a child of Point, although I'd be happy for it
to be a sibling.  Complexes only become points when you put them on graphs, and
then it is legitimate to convert them (especially because the graph might be 3D
anyway).

Just my $0.02

... John