I discovered something interesting working with VisualWorks Rectangles this evening. I had created a temporary rectangle to assist in defining a path for my Cairo presentation. It was all in "unit space," meaning it was all somewhere within the recttangle (0.0@0.0 corner: 1.0@1.0). The rectangle was in fact something like (0.46@046 corner: 0.54@0.54).
I was happily coding along using the corners of the rectangle (topLeft, topRight, bottomLeft, bottomRight) and I came to the conclusion that it would look cooler if I rotated my shape by 45 degrees, so I decided to use topCenter, leftCenter, rightCenter, and bottomCenter.
And everything broke. The shape went all over the place.
I poked around for a while and only when I started questioning fundamental assumptions, did I happen upon the problem. The code for the center APIs all uses the expression value // 2. Either directly, or by using the center method. This produces some interesting results:
(0.3@0.3 corner: 0.7@0.7) center --> 0@0 "It doesn't even lie within the rectangle!"
(0.3@0.3 corner: 0.7@0.7) topCenter --> 0@0.5 "definitely not colinear with it's topLeft and topRight counterparts"
Checking around, it appears that Squeak is afflicted of the same. As is VSE. Ambrai Smalltalk is broken too. It reuses the center method in the others but implements center as ^origin + (extent // 2), which has the interesting property of pushing everything to the topLeft of a unit rectangle. Guess what Smalltalk/X does? It gets it right. If anyone would care to leave a comment as to how Dolphin, GNUSmalltalk, VistaSmalltalk, or VisualAge behave, I would appreciate it. In my mind, this is just plain shortsighted and wrong. Yes, I understand the motivation. It's still not justified. A rectangle is a rectangle and it's center seems pretty clear to me. One should be able to count on topCenter being consistent with topLeft and topRight. The only person i can think of that would appreciate this type of behavior would be Escher. He liked Rectangles that appeared to be inconsistent with themselves.