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 <siguctua at gmail.com> wrote:
> On 2 January 2013 12:55, H. Hirzel <hannes.hirzel at 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 at gmail.com> wrote:
>>> On 24 December 2012 09:43, H. Hirzel <hannes.hirzel at 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 at 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.
>>>>
>>>>    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.
>