On Tue, Oct 11, 2011 at 1:28 AM, Nicolas Cellier <[email protected]> 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/
