On Tue, Jan 12, 2016 at 6:02 PM, David Allouche <david@allouche.net> wrote:
I wonder whether it would be worth reversing this change, to remove an unnecessary incompatibility with other dialects.
Of course we should not introduce *unnecessary* incompatibilities, but its be hard to judge the subtle dampening effect of compatibility on innovation & API cleaning, against the benefits obtained from these. So Pharo tends to favour the latter over the former. Equally, mistakes sometimes aren't apparent until later, so no "improvement" should be treated as golden goose. I'm not qualified to have an opinion in this case, but I remember several people being quite pleased with the change. You'd probably have to clearly identify other benefits of reverting. (Compatibility with existing Morphic examples noted.)
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.
You may find interesting the first three chapters... https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf cheers -ben
On 11 Jan 2016, at 22:25, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> 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 <stephan@stack.nl>:
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