On 2 January 2013 12:55, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello again Igor and Happy and Successful New "Pharo" Year 2013
Thanks Hannes :) Wish best to you in New Year too :)
--Hannes
my notes are inserted below.
On 12/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 December 2012 09:43, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello Igor
Thank you for this interesting mail. An issue over 11 years old, see below.
On 12/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
Hi,
just wanna share some ideas about how we can cleanup morph a bit.
A bit? It will be a lot of effort.
We can do it in small steps.
Squeak 4.4-12234 (current)
Morph selectors size 1183
Pharo 2.0 (Beta)
Morph selectors size 865
Cuis 4.1 (18th Dec 2012)
Morph selectors size 343
This was an issue in 2001
http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt
see
I am not first day here, of course i am aware of this :)
Did you start working with Squeak already in 2001?
no. But i know this is a long standing issue :)
Layout.. bizarre.
Yes, see humorous contribution from June 2001 http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt
search for
the Morph class has 924 methods
in that mails
There was an effort Morphic Cleanup Project
http://wiki.squeak.org/squeak/3005
lead by
Diego Gomez Deck
It produced some results. But they did not reach far enough.
yes yes.. i know.
However Juan Vuletic was successful in coming up with a simpler Morphic in Cuis.
search this mailing list for Small Morphic. It was an attempt to use Juan's work, which didn't fly.
Of course I am aware of SmallMorphic. If a first attempt at integrating SimpleMorphic into Pharo was not successful it does not necessarily mean that a second one has to be a failure again.
Time spent on an analysis why it didn't fly is surely not a waste.
For example another approach could be instead of copying code from Cuis and implanting it into Pharo "blob style" you could follow Juan Vuletich's refactoring steps incrementally and copy smaller chunks of code. Cuis had many releases until it reached version 4.1.
In terms of factoring out classes from the class Morph you seem to want to do that anyway.
See for example
http://www.jvuletich.org/Cuis/CuisReleaseNotes.html New in Cuis 2.7 (released September 3, 2010)
* Morphic. New LayoutSpec mechanism. Simpler and nicer. * Morphic Simplification: Layout, Extensions, etc
Well, one thing is that Juan doing quite radical changes to code. He is not concerned about backwards compatibility (but unlike from Pharo, nobody raising it as an issue over and over again ;) ). Yes, i checked new Cuis code. I see a lot of simplifications. But also i see reduced functionality. For instance, i did not found things like 'fill style', and themes. Also, i see some protocols is renamed, in preparation for something bigger (morphic 3 i guess ;) So, i agree we should not copy/paste the code. Because it won't fly. We should gradually analyze it and improve ours step by step. Layout code in Cuis is somewhat similar to what i proposing. But my proposal is essentially about approach, which you can apply to anything.. not just layouts in Morphics.
There are so many methods dedicated to laying out morphs that it easy to get lost.
Cuis has a new layout system.
Worth to check out.
Sure.
Fine.
For me the main mystery and source of confusion is that there actually two different groups:
- methods to control morph's own layout (in respect to its parent) - methods to control morph's children layout (something called layoutPolicy)
the problem is that both APIs are found in single class,
which one?
Morph
and most of
them contain 'layout' word in it, so it is really hard to determine which one to use and when..
Over a years, i seen that people learned how to use existing functionality, without delving deep into implementation detail.
Yes.
But if you try to extend/change behavior (in your subclass), you will quite soon find out that it is really hard to tell with 100% certainty that the methods you override is the right place for your customization.
Yes, this actually has made development very difficult. In such a way that most people have abandoned it. Very few GUIs are actually built with it.
Also, an important detail is extremely polluted protocol(s), making Morph a GOD class,
Morph is at the root of a large subclasses tree. The question is: what can be pushed down or factored out. An analysis in terms of number of method candidates to move out would surely be a good thing to know.
-- Best regards, Igor Stasenko.