Inverting the origin and the corner of a rectangle changes the result of intersection. I guess it's a bug, though I imagine that changing the code of Rectangle is likely to have deep/undesired consequences.. (0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false !!!! Noury
From the st80 ages, rectangle have allways been oriented. You have an origin and a corner inst var, not 2 corners or vertices. And you have creation messages Rectangle class>>origin:corner: The conventions are that of latin scribes, the orientation of rectangle should be (left->right , top->down)
There is an assumption that a rectangle with negative width (right->left) or height (bottom->top) should be treated as empty. And this was globally well maintained except a few breakages introduced in Squeak along the years (but I hope I corrected most of the slips since then). Now Igor and Stephane had another view more geometric and un-oriented, and wanted to change conventions/handling of empty rectangles in Pharo. I don't know how far they went, or even if it is feasible at all... IMO, it's a recipe for maximizing breakage/gain ratio. Note that VW has Rectangle class>>vertex:vertex:, and we probably should add such message... 2014-03-21 15:15 GMT+01:00 Noury Bouraqadi <bouraqadi@gmail.com>:
Inverting the origin and the corner of a rectangle changes the result of intersection. I guess it's a bug, though I imagine that changing the code of Rectangle is likely to have deep/undesired consequences..
(0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false !!!!
Noury
2014-03-22 12:20 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
From the st80 ages, rectangle have allways been oriented. You have an origin and a corner inst var, not 2 corners or vertices. And you have creation messages Rectangle class>>origin:corner: The conventions are that of latin scribes, the orientation of rectangle should be (left->right , top->down)
There is an assumption that a rectangle with negative width (right->left) or height (bottom->top) should be treated as empty. And this was globally well maintained except a few breakages introduced in Squeak along the years (but I hope I corrected most of the slips since then).
Now Igor and Stephane had another view more geometric and un-oriented, and wanted to change conventions/handling of empty rectangles in Pharo. I don't know how far they went, or even if it is feasible at all... IMO, it's a recipe for maximizing breakage/gain ratio.
Note that VW has Rectangle class>>vertex:vertex:, and we probably should add such message...
Something like:
Point>>vertex: aPoint ^aRectangle vertex: self vertex: aPoint Rectangle class>>vertex: point1 vertex: point2 ^self origin: (point1 min: point2) corner: (point1 max: point2)
2014-03-21 15:15 GMT+01:00 Noury Bouraqadi <bouraqadi@gmail.com>:
Inverting the origin and the corner of a rectangle changes the result of
intersection. I guess it's a bug, though I imagine that changing the code of Rectangle is likely to have deep/undesired consequences..
(0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false !!!!
Noury
2014-03-22 12:23 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2014-03-22 12:20 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
From the st80 ages, rectangle have allways been oriented.
You have an origin and a corner inst var, not 2 corners or vertices. And you have creation messages Rectangle class>>origin:corner: The conventions are that of latin scribes, the orientation of rectangle should be (left->right , top->down)
There is an assumption that a rectangle with negative width (right->left) or height (bottom->top) should be treated as empty. And this was globally well maintained except a few breakages introduced in Squeak along the years (but I hope I corrected most of the slips since then).
Now Igor and Stephane had another view more geometric and un-oriented, and wanted to change conventions/handling of empty rectangles in Pharo. I don't know how far they went, or even if it is feasible at all... IMO, it's a recipe for maximizing breakage/gain ratio.
Finally, it seems that the conventions about emptyness were preserved in Pharo so far, as you can notice in Rectangle comment. Though, the Squeak changes ensuring this invariant still do not have been integrated: https://code.google.com/p/pharo/issues/detail?id=2601 https://pharo.fogbugz.com/f/cases/2649/don-t-let-an-empty-Rectangle-intersec... (A change of bug number is not the best thing here, it make things harder to follow... like my remarks in https://pharo.fogbugz.com/f/cases/7108/Rectangle-intersects-and-if-none) Note that VW has Rectangle class>>vertex:vertex:, and we probably should
add such message...
Something like:
Point>>vertex: aPoint ^aRectangle vertex: self vertex: aPoint
Rectangle class>>vertex: point1 vertex: point2 ^self origin: (point1 min: point2) corner: (point1 max: point2)
2014-03-21 15:15 GMT+01:00 Noury Bouraqadi <bouraqadi@gmail.com>:
Inverting the origin and the corner of a rectangle changes the result of
intersection. I guess it's a bug, though I imagine that changing the code of Rectangle is likely to have deep/undesired consequences..
(0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false !!!!
Noury
https://pharo.fogbugz.com/default.asp?13116
Point>>vertex: aPoint ^aRectangle vertex: self vertex: aPoint
Rectangle class>>vertex: point1 vertex: point2 ^self origin: (point1 min: point2) corner: (point1 max: point2)
2014-03-22 12:23 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2014-03-22 12:20 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
From the st80 ages, rectangle have allways been oriented.
You have an origin and a corner inst var, not 2 corners or vertices. And you have creation messages Rectangle class>>origin:corner: The conventions are that of latin scribes, the orientation of rectangle should be (left->right , top->down)
There is an assumption that a rectangle with negative width (right->left) or height (bottom->top) should be treated as empty. And this was globally well maintained except a few breakages introduced in Squeak along the years (but I hope I corrected most of the slips since then).
Now Igor and Stephane had another view more geometric and un-oriented, and wanted to change conventions/handling of empty rectangles in Pharo. I don't know how far they went, or even if it is feasible at all... IMO, it's a recipe for maximizing breakage/gain ratio.
Note that VW has Rectangle class>>vertex:vertex:, and we probably should add such message...
Something like:
Point>>vertex: aPoint ^aRectangle vertex: self vertex: aPoint
Rectangle class>>vertex: point1 vertex: point2 ^self origin: (point1 min: point2) corner: (point1 max: point2)
Oh, I see that this exists already, it's named (point1 rect: point2) in Squeak and (point1 rectangle: point2) in Pharo3.0, so Noury that's what you should be using.
2014-03-21 15:15 GMT+01:00 Noury Bouraqadi <bouraqadi@gmail.com>:
Inverting the origin and the corner of a rectangle changes the result of
intersection. I guess it's a bug, though I imagine that changing the code of Rectangle is likely to have deep/undesired consequences..
(0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false !!!!
Noury
From the st80 ages, rectangle have allways been oriented. You have an origin and a corner inst var, not 2 corners or vertices. And you have creation messages Rectangle class>>origin:corner: The conventions are that of latin scribes, the orientation of rectangle should be (left->right , top->down)
There is an assumption that a rectangle with negative width (right->left) or height (bottom->top) should be treated as empty.
And this was globally well maintained except a few breakages introduced in Squeak along the years (but I hope I corrected most of the slips since then).
Now Igor and Stephane had another view more geometric and un-oriented, and wanted to change conventions/handling of empty rectangles in Pharo. I don't know how far they went, or even if it is feasible at all... IMO, it's a recipe for maximizing breakage/gain ratio.
It is clearly not. :) We removed bugs in the invalid rectangle areas and others. And we fixed all the places that were created negative dimensions (like in framelayout) because rectangle where hijack to represent two points that were not a rectangle. We also introduce margin which is really nice to represent 1,2, or 4 digits and avoid to overuse again a rectangle.
Note that VW has Rectangle class>>vertex:vertex:, and we probably should add such message...
2014-03-21 15:15 GMT+01:00 Noury Bouraqadi <bouraqadi@gmail.com>: Inverting the origin and the corner of a rectangle changes the result of intersection. I guess it's a bug, though I imagine that changing the code of Rectangle is likely to have deep/undesired consequences..
(0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false !!!!
Noury
2014-03-22 16:59 GMT+01:00 Pharo4Stef <pharo4Stef@free.fr>:
From the st80 ages, rectangle have allways been oriented. You have an origin and a corner inst var, not 2 corners or vertices. And you have creation messages Rectangle class>>origin:corner: The conventions are that of latin scribes, the orientation of rectangle should be (left->right , top->down)
There is an assumption that a rectangle with negative width (right->left) or height (bottom->top) should be treated as empty.
And this was globally well maintained except a few breakages introduced in Squeak along the years (but I hope I corrected most of the slips since then).
Now Igor and Stephane had another view more geometric and un-oriented, and wanted to change conventions/handling of empty rectangles in Pharo. I don't know how far they went, or even if it is feasible at all... IMO, it's a recipe for maximizing breakage/gain ratio.
It is clearly not. :) We removed bugs in the invalid rectangle areas and others. And we fixed all the places that were created negative dimensions (like in framelayout) because rectangle where hijack to represent two points that were not a rectangle. We also introduce margin which is really nice to represent 1,2, or 4 digits and avoid to overuse again a rectangle.
You did not fix everything that was fixed in Squeak. Example: rect1 := 10@10 corner: 40@40. empty2 := 30@30 corner: 20@20. (rect1 intersects: empty2) - > true What I see is that you provided intersect:ifNone: to avoid producing empty rectangle in the first place - or to produce explicitely empty 0@0 extent: 0@0. But - not all intersect: senders have been changed, - some senders have been changed questionably (allowedArea in IdentifierChooserMorph is re-implementing RealEstateAgent class maximumUsableArea differently) - I don't know if intersect: was the sole source of empty rectangles... Until all producers have been eradicated, the empty invariant still exists, and Rectangle methods must still be guarded against empty rectangle edge cases. Right now, it is not enforced everywhere (see intersects: case above). Right now you're in the middle of the bridge, but that's OK if the emptiness invariant eradication is still planned, it's just a temporary transition.. Note that VW has Rectangle class>>vertex:vertex:, and we probably should
add such message...
2014-03-21 15:15 GMT+01:00 Noury Bouraqadi <bouraqadi@gmail.com>:
Inverting the origin and the corner of a rectangle changes the result of intersection. I guess it's a bug, though I imagine that changing the code of Rectangle is likely to have deep/undesired consequences..
(0@0 corner: 100@100) intersects: (-50@ -50 corner: 80@80) ==> true (100@100 corner: 0@0) intersects: (-50@ -50 corner: 80@80) ==> false !!!!
Noury
You did not fix everything that was fixed in Squeak. Example:
rect1 := 10@10 corner: 40@40. empty2 := 30@30 corner: 20@20. (rect1 intersects: empty2) - > true
I think that we should not use intersect: anymore because it does not make sense.
What I see is that you provided intersect:ifNone: to avoid producing empty rectangle in the first place - or to produce explicitely empty 0@0 extent: 0@0.
But - not all intersect: senders have been changed, Indeed we should probably continue
- some senders have been changed questionably (allowedArea in IdentifierChooserMorph is re-implementing RealEstateAgent class maximumUsableArea differently) - I don't know if intersect: was the sole source of empty rectanglesâ¦
No around 160 layoutFrame and others
Until all producers have been eradicated, the empty invariant still exists, and Rectangle methods must still be guarded against empty rectangle edge cases. Right now, it is not enforced everywhere (see intersects: case above).
Right now you're in the middle of the bridge, but that's OK if the emptiness invariant eradication is still planned, it's just a temporary transition..
If I remember correctly the goal is to never have never width.
participants (3)
-
Nicolas Cellier -
Noury Bouraqadi -
Pharo4Stef