Craig's NAIAD stands for "Name And Identity Are Distinct". Just
thinking aloud -- because Morphic is so entrenched.. Could NAIAD or Colin's Environments allow Juan's Morphic (or, Morphic3) to co-exist with original Morphic, so that it would allow working on the port without depending on it for the tools? Once the port was complete, a sane migration could more easily occur.. On Wed, Jan 2, 2013 at 7:00 AM, Igor Stasenko <[hidden email]> wrote: > On 2 January 2013 12:55, H. Hirzel <[hidden email]> 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 <[hidden email]> wrote: >>> On 24 December 2012 09:43, H. Hirzel <[hidden email]> wrote: >>>> Hello Igor >>>> >>>> Thank you for this interesting mail. An issue over 11 years old, see >>>> below. >>>> >>>> On 12/24/12, Igor Stasenko <[hidden email]> 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. >>>> >>>> http://www.jvuletich.org/Cuis/Index.html >>>> >>> 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. > |
On Wed, Jan 2, 2013 at 1:52 PM, Chris Muller <[hidden email]> wrote:
Yeah. I've also been thinking we could do something like this to turn Etoys into a package. Colin |
Free forum by Nabble | Edit this page |