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@keyww.com