[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