Double dispatching and Point

Travis Griggs tgriggs at keyww.com
Mon Feb 2 18:37:36 UTC 1998


David N. Smith wrote:

> At 22:45 -0500 1/31/98, Travis or Kerrin Griggs wrote:
> >In doing this, I found that the by the time I was done with
> >Point, it would have been much easier to make Point a subclass of Number.
> >I could
> >probably get rid of quite a few messages that way as well. 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."
>
> Consider the following examples. In the first case, (2 at 2) is indeed less
> than (3 at 3). In the next two however, (4 at 6) is neither greater than nor less
> than (5 at 5).
>
> (2 at 2) < (3 at 3)
>  true
>
> (5 at 5) < (4 at 6)
>  false
>
> (5 at 5) > (4 at 6)
>  false
>
> However, to be a magnitude #< and #> must be defined for all values such
> that if the values are not equal either #< or #> will answer true. The
> comment for class Magnitude says:
>
>   I am an abstract representation of objects that measure something linear.
>
> If one object can be neither less-than nor greater-than another then the
> objects are not 'linear'.
>
> Note that at least one major Smalltalk implementation (not IBM) gets this
> wrong. I guess it's OK if inheritence is considered strictly for
> implementation purposes, but that's how one ends up with Process being a
> subclass of a collection (as in some Digitalk systems).
>
> I'd vote for having some is-a view point mixed in with the
> only-implementation viewpoint.

Good points. I have never found any use for the Point < method as defined. 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. Does anyone use it to
their benefit as implemented now, and in such a way that would make the above
undesireable?

What are the arguments against turning the heirarchy there upside down? IOW

Object
    ArithmeticValue
        LinearMagnitude
            Number
        Point

Travis Griggs
Key Technology
tgriggs at keyww.com





More information about the Squeak-dev mailing list