On Mon, Oct 10, 2011 at 08:28:40PM +0200, Nicolas Cellier wrote:
> 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 ?

I do not use Complex, but I very much like having it in the image 
because it makes complex arithmetic easy to explore, and makes the
system feel more complete. In a way, I think that Complex has more
justification for being in the image than Float, because Complex
represents fundamental concepts, whereas Float is really just a
hardware performance optimization ;)

To me it feels natural to have Complex categorized with numbers,
but if that makes it harder to support or harder to adopt in other
images, then it would not bother me to have it in another package.

Changing the name to ComplexNumber would not matter to me, either
name would make sense.

Thanks!
Dave