On Tue, Oct 11, 2011 at 1:28 AM, Nicolas Cellier <nicolas.cellier.aka.nice@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) ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/