Hi,

Facts:
- Complex is present in Squeak trunk image but not used in Kernel
- Complex is absent from Pharo image.
This breaks portability of some packages.

I suggest putting Complex in its own package in squeaksource. This can
work for Pharo alone.
I also suggest to optionally remove Squeak.Complex from trunk.

There are then other choices:
- the name of the package : can be Complex or Math-Complex (I already
put a few Math-* in squeak source...)
- the name of the class can be Complex or ComplexNumber
Specifically I don't like isComplex, many objects could respond true
because complicated;
isComplexNumber is much more explicit.
We could also think of having complex expressions in a symbolic
algebra, and isComplexNumber would be true only for a literal value..

What I could eventually do is publish an old Complex in package
Complex for backard compatibility and an updated ComplexNumber in a
Math-Complex package...

How many of you use Complex ?
What do you think of these proposals ?

Nicolas