[squeak-dev] Re: [Pharo-project] Migrating Complex in a separate package

Serge Stinckwich serge.stinckwich at gmail.com
Tue Oct 11 02:33:09 UTC 2011

On Tue, Oct 11, 2011 at 1:28 AM, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> Hi,

Hi Nicolas,

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

Thank you for bringing up this issue ;-)

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

Yes i think this will be easier for you to have just one package in
Squeaksource for Pharo and Squeak.

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

Math-Complex is ok for me.

> - 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'm mostly using Complex and Quaternion for my robotic development.
So i want to be able to load these packages in a current Pharo image.

Maybe you can merge everything about complex, quaternions (and latter
octonions) numbers in a single package in order to avoid too much
small packages with just a class (and a test class) ?

Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk

More information about the Squeak-dev mailing list