[squeak-dev] Rectangle >> intersects: "degenerate case" --
*wrong* behavior??
Jim Rosenberg
jr at amanue.com
Thu Jan 17 01:56:37 UTC 2013
--On Tuesday, January 15, 2013 01:49:26 +0100 Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> Well, the old behavior of intersects: was wrong with respect to intersect:
>
> This is because intersect: answer an "empty" rectangle (negative width
> or height).
> Such intersection HAS TO BE EMPTY, and thus cannot intersects: anything...
>
> To accomodate the degenerated case (one null dimension, the other
> positive or null) we can change the final tests to strict
> inequalities. OK?
Hmm ...
I guess changing to strict inequality would be OK with *me* -- as far as
not breaking any of my own code -- but I'm still wondering whether silently
returning false from Rectangle >> intersects: in the case of "negative
height" or "negative width" is the right behavior.
The issue here, as I understand it, is that a "rectangle" where the origin
and corner are not top-left and bottom-right is "incorrectly specified".
So, if Rectangle >> intersects: can't really handle an incorrectly
specified rectangle, should it return false, or throw an error?
Of course changing the behavior to throw an error could break somebody
else's code, which I wouldn't want to do.
What should Rectangle origin: (25 at 250) corner: (100 at 100) produce? A
rectangle starting from (25 at 250) and ending at (100 at 100) certainly makes
semantic sense. But it's "incorrectly specified". Should it throw an error?
Should it produce the same thing as
Rectangle origin: (25 at 100) corner: (100 at 250)? Should there be a new class
method, say Rectangle from: (25 at 250 to: (100 at 100) which would be guaranteed
to produce the rectangle with origin (25 at 100) and corner (100 at 250)? Should
Rectangle >> intersects: "normalize" both the receiver and argument before
calculating whether things intersect?
What "is" a rectangle? How is the Squeak user supposed to know? There are
at least two interpretations of what "rectangle" might mean:
(1) a 4-sided polygon where all 4 sides are strictly horizontal or strictly
vertical, determined by two diagonally opposite points.
(2) a 4-sided polygon where all 4 sides are strictly horizontal or strictly
vertical, determined by the top-left point ("origin") and bottom-right
point ("corner").
Maybe I'm being unfair, but it seems to me things aren't really clear from
one method to the next what the semantics are supposed to be. I'm getting
the idea that the intent is that the semantics of "rectangle" are supposed
to be (2). Well, OK, as long as we all know that; but in this case,
shouldn't Rectangle origin: (25 at 250) corner: (100 at 100) throw an error?
But then that's almost certain to break *somebody's* code ...
It's a puzzle.
More information about the Squeak-dev
mailing list
|