Re:intersect: when intsersects: is false

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re:intersect: when intsersects: is false

Jerome Peace
[squeak-dev]

>Tobias Pape Das.Linux at gmx.de
>Sun Jun 20 14:40:10 UTC 2010
>
>
>Hello,
>
>Am 2010-06-20 um 15:02 schrieb Nicolas Cellier:
>
>> ((100 at 100 corner: 50 at 50) rotateBy: #pi centerAt: 0 at 0) area -> 2500.
>> Rotating an empty rectangle does not preserve its emptyness.
>
>
>Why shall (100 at 100 corner: 50 at 50) be an empty rectangle?
>I do not understand. Especially, why is
>(100 at 100 corner: 50 at 50) = (50 at 50 corner: 100 at 100)
>false?
>Isn't it just the same Rectangle, albeit, rotated?
>
Contrast:

{ 100 asPoint corner: 50 asPoint
. 100 asPoint rect: 50 asPoint }

The former is not a proper rectangle. I recently noticed the same fallacy on the pharo list. For some reason people assumes that #corner: guarantees a proper rectangle. It does not. It is a speed "short cut" for when the user takes responsibility for that origin < corner .

Using #corner: instead of the more general rect: is such a common bug there should be a lint rule for it. Or at least a smell test.

Form from user had this bug also. The user could select to create an improper rectange and things wouldn't blow up until someone tried to use the form.

Area handles improper rectangles by assigning them a zero area. That is actually used in some places to determine if a form is proper. Doesn't work well enough because it is an obscure check.

Yours in curiosity and service, --Jerome Peace, Cheerful bug tracker.