Patrick Logan wrote:

> >>> Is there a good reason not to make Point a subclass of Number?
> >>
> >> Yes, points are not magnitudes! The definition of #< in Point contains the
> >> note:
> >>    "Answer whether the receiver is above and to the left of aPoint."
> >> while #> contains the comment:
> >>    "Answer whether the receiver is below and to the right of aPoint."
> >...
> > I have had reason to sort Points quite often, and have always done so
> > using the following sort block:
> >
> > [:a :b | a y = b y ifTrue: [a x < b x] ifFalse: [a y < b y]]
> >
> > True, it establishes a convention, but I've never wanted ambiguous sorting of
> > Points. Why not change the definition of < for Point.
>
> (1) What are some of the reasons you (Travis) or anyone has had to
>     sort Points linearly?

I did a bunch of stuff where things were stored in grids (non-continuous) and I was
always wanting to sort them in the same repeatable fashion.

> (2) Why not implement the range comparison messages to
>     #shouldNotImplement or something like that?

I like this. I like this alot. And with double dispatching, it would be cinche.
Point might implement:

Point>>lessFromNumber: aNumber
    ^self shouldNotImplement


>
>
> (3) Point is a two-dimensional value. It cannot be made linear. Maybe
>     the Block above works for a specific purpose. But it is no better
>     than the relational comparison definitions, above. I'd vote for
>     (#2), throwing an exception, as the simplest solution that makes
>     the most general sense. YMMV.
>
> >What are the arguments against turning the heirarchy there upside down? IOW
> >
> >Object
> >    ArithmeticValue
> >        LinearMagnitude
> >            Number
> >        Point
>
> Some Magnitudes should not implement the math messages.

Woops, duh. I should turm my brain on and think before I suggest these things. They
say that the only dumb question is one that is not asked... :)

Travis Griggs
Key Technology
tgriggs at keyww.com