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