area "Answer the receiver's area, the product of width and height." | w | (w := self width) <= 0 ifTrue: [ ^ 0 ]. ^ w * self height max: 0 what i found that rectangles don't like if corner point having coordinates (either x or y) which is below the origin. many places in code (and especially in morphic) assuming that for any rectangle: rect origin >= rect corner. On 6 April 2011 13:51, Andre Hora <andrehoraa@gmail.com> wrote:

Hello,

VW: (Rectangle origin: (0@0) corner: (10@10)) area. 100 (Rectangle origin: (0@10) corner: (10@0)) area. -100 (Rectangle origin: (10@10) corner: (0@0)) area. 100 (Rectangle origin: (10@0) corner: (0@10)) area. -100

Pharo: (Rectangle origin: (0@0) corner: (10@10)) area. 100 (Rectangle origin: (0@10) corner: (10@0)) area. 0 (Rectangle origin: (10@10) corner: (0@0)) area. 0 (Rectangle origin: (10@0) corner: (0@10)) area. 0

On Wed, Apr 6, 2011 at 1:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Give us the code! In VW and Pharo side by side and their results

Stef

On Apr 6, 2011, at 10:31 AM, Andre Hora wrote:

...

Hello,

To create a Rectangle in Pharo with the method Rectangle>>origin:corner:, you must provide the top left and the bottom right points. With others you have a Rectangle with area equals to zero. I just noticed that in VW it is possible create a Rectangle with other points (bottom right and top left, bottom left and top right, ...). So, shouldn't Pharo Rectangle allow the same?

regards,

-- Andre Hora

-- Andre Hora

-- Best regards, Igor Stasenko AKA sig.

On 6 April 2011 22:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Thanks andre Igor I'm sure that we can understand the implementation of area. I asked andre to post it because I was concerned that this difference of behavior is a bit odd. And I wanted to raise awareness and may be that we question ourselves. Now I do not have that much preconceived point of view on it.

Me neither. I found it odd that some pieces of code relying that origin <= corner (sorry i mistaken in previous mail) i meant that origin x <= corner x origin y <= corner y and yes, there is some code that assumes it is always like that. So, yes. While in pure geometry two different corner points could define a rectangle, no matter in what order you put them, in pharo/squeak geometry it sometimes matters :) But of course you can try and figure out what is works and what not, and fix it :)

Stef

-- Best regards, Igor Stasenko AKA sig.

On Wed, Apr 6, 2011 at 11:09 PM, Igor Stasenko <siguctua@gmail.com> wrote:

Me neither. I found it odd that some pieces of code relying that origin <= corner (sorry i mistaken in previous mail)

i meant that

origin x <= corner x origin y <= corner y

and yes, there is some code that assumes it is always like that.

So, yes. While in pure geometry two different corner points could define a rectangle, no matter in what order you put them, in pharo/squeak geometry it sometimes matters :)

But of course you can try and figure out what is works and what not, and fix it :)

hmm.. I am not sure if this would improve situation or make situation even more ugly, but maybe #origin:corner: could figure out how to create rectangle from given parameters that satisfies: new_origin x <= new_corner x new_origin y <= new_corner y in other words, resulting rectangle may have different origin and corner than one supplied to #origin:corner: Davorin Rusevljan http://www.cloud208.com/