I wonder whether it would be worth reversing this change, to remove an unnecessary incompatibility with other dialects.
But maybe there is no development activity outside of Pharo, that would justify making any effort to maintain compatibility. I do not know. Practicality beats purity, if cleaning up existing APIs means cutting out Pharo from a wider ecosystem, and introducing painful bitrot, it might not be worth the cost. > On 11 Jan 2016, at 22:25, Nicolas Cellier > <[email protected]> wrote: > > And it probably won't be integrated in Squeak, because it's not worth the > pain. > > The change was conducted without analyzing all the impacts, because it was > probably not possible to analyze the huge code base. > (though it would have been possible to instrument code and collect the sender > stacks producing degenerated rectangles) > > The only motto was to make code more "pure". > Generally, I tend to be wary... > > On the other hand, storing the offsets in a rectangle just because there are > 4 edges is sort of hackish usage, so while at cleaning... > > 2016-01-11 9:42 GMT+01:00 Stephan Eggermont <[email protected] > <mailto:[email protected]>>: > On 10-01-16 23:16, Thierry Goubier wrote: > Hi David, > > this is the bug with LayoutFrame>>#fractions:offsets: we were talking > about relative to that class comment. > > In Pharo, Rectangles are constrained to have the smallest vertical value > as the top, smallest horizontal value as the left, largest vertical > value as bottom and largest horizontal value as right. > > Indeed. And there is no Morphic documentation at all that is aware of that, > as nearly all of it was written before we changed the behavior of Rectangle > in Pharo, and it is a change that is not done in Squeak. The result is that > nearly no old Morphic code will run unmodified in Pharo. > > I would like to collect a list of these gotchas, preferably with solutions, > to make it easier for people to update/migrate old morphic code. Post them > here, or mail them to me. > > Stephan > > > > >
