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.
Hum.
That change induced a lot of pain because touching Rectangle is very
invasive (tend to crash the GUI), but I can't avoid thinking that
places creating those strange rectangles were in fact bugs.
They were bugs. This API is plain crap.
It produces intermediate objects for nothing.
Now we have margin.
For LayoutFrame, a simple refactoring when importing Morphic code
would do the trick.
In practice, a significant amount of code in Pharo 5 still creates
wrong rectangles.
Less and less. We spent a lot of time chasing them. We used the trick of
nicolas to spot them based on exception.
and I would be curious to see if some degenerated rectangles are left.
Then it is important to clean it because we end up having from clipping
and the code just worked because
primitives werer robust.
A specific package even added an API to Rectangle to be able to do so.
Bad idea.
Thierry
On 11 Jan 2016, at 22:25, Nicolas Cellier
<[email protected]
<mailto:[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
