If the goal is to fix Number vs. Complex comparison, isn't the correct 
behavior to renormalize Complex numbers when they are indeed reals? 
I.e., my attitude would be to fix Complex such that (1 + 0i) results in 
a real number (the integer 1) instead of the complex (1 + 0i). In which 
case the comparison problem solves itself. Lacking this, I would rather 
have comparison fail for real vs. complex and require clients to be 
explicit where they mix them, e.g., force you to write "x asComplex = y".

In any case, pretending to be a number when indeed Complex is lacking 
half of the protocol of numbers is not the right way to address the problem.

Cheers,
   - Andreas

nicolas cellier wrote:
> 
> Though my advice was to keep this change out of the image, it came in 
> 3.9 or 3.10, i don't know...
> Complex isNumber allows a lightweight fix of Number = Complex bug.
> 
> BUT TOO MUCH CODE RELY ON A DIFFERENT BEHAVIOUR!
> 
> In less of one minute of browsing, i can construct a fail test like:
> 
> self shouldnt: [Dictionary at: 1 i  put: 'a complex number'; at: 2 put: 
> 'a number'; explore] raise: Error
> 
> Guess what, the failing method is called keysSortedSafely... But with 
> this change in, nothing that was safe yesterday will be safe again ;-).
> 
> 
> 
> I recommend AGAIN to browse senders of isNumber and find maybe the one 
> or two that are prepared for an instance of Complex.
> 
> MOST are expecting (isKindOf: Number), and not any number out of the set 
> of real numbers.
> 
> This is consistent with traditional Smalltalk implementation, all 
> subInstances of Number are in the set of real
> (well except Float nan and Float infinity which were not in St-80).
> 
> 
> 
> I proposed isNumberExtension so that other Number extensions like 
> Quaternion can be added too without a rewrite 
> (http://bugs.squeak.org/view.php?id=2688).
> 
> This had no success, maybe the selector is not very well chosen...
> I don't care, call it what you want, but please, not isNumber,
> 
> 
> 
> The bugs are minor, because fortunately, Complex are hardly ever used, 
> so we can as well let this change rot in the image as is.
> 
> Personnally, i vote thumb down.
> 
> Nicolas
> 
> 
>