Yes this is strong reasoning.�� In fact nowadays a similar argument is used to explain why a hierarchy of geometric plane figures shall not have Circle as subclass of Ellipse (same for Square versus Rectangle). See http://en.wikipedia.org/wiki/Circle-ellipse_problem for an elaboration.

It follows from the "Liskov Substitution Principle".

Em 15/08/2009 17:17, Igor Stasenko < siguctua@gmail.com > escreveu:

Btw, here is another argument why Complex is not part of Number class hierarchy.

Here what reads the Magnitude class:

I'm the abstract class Magnitude that provides common protocol for
objects that have
the ability to be compared along a ___linear dimension___, such as
dates or times.
Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as
Character and LookupKey.

---

Since complex values is not scalars and hence cannot be compared along
a linear dimension, they could not be inherited from a Magnitude.

Btw this comment seems veeery dated, because it refers to
ArithmeticValue, which not present in current class hierarchy :)

As you stated earlier that Real set is a subset of Complex, then if
you want to see both of them lying in same class hierarchy,it could require a major redesign the class hierarchy to make Complex
a base class, and Float/Integer a subclasses.
Since subclasses are specialization of superclasses, and superclass
always is more generic than any of its subclass.

Others could step up and say: hey scalars could be seen as a
specialized kind of vectors, and vectors could be seen as a
specialized kind of matrices, so lets make
Matrix to be the ultimate superclass, and then Vector, and then Scalar etc etc..

I can only guess, how far we can go with such generalization(s).

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project