[Cuis] PluggableListMorph

[Juan Vuletich]

On 23/10/2015 12:56 p.m., Dan Norton wrote:
> On 22 Oct 2015 at 15:39, KenD wrote:
>
>> On Tue, 20 Oct 2015 16:43:02 -0400
>> "Dan Norton"<dnorton at mindspring.com>  wrote:
>>
>>> PluggableListMorph has valuable behavior but applying it in morphs
>> with multiple lists can be
>>> daunting because of the use of the dependency mechanism. AFAICT
>> the tools do not display
>>> dependencies and even if they did, it's not clear why some of them
>> exist.
>>> What is needed is a "PluggableListMorph Principles of Operation"
>> doc, or something similar
>>> that can be in the Terse Guide. It should show an example of
>> selection in one list causing the
>>> population of another list and selection in that list causing the
>> population of some other
>>> morph. Isn't that like FileList? Yes, but we need the whys and
>> wherefors. For example, a
>>> method sends #changed: with a parameter referring to another
>> method - why? The design
>>> needs to be explained.
>> Dan,
>>
>> +1
>>
>> A tool to detect/show such "out of band" control/change
>> linkages/dependencies would be most welcomed, as would a Principles
>> of Operation.
>>
>> Taking a quick look at my own code ("guilty as charged, sir")
>>
>>>> grep "changed:" */*.st
>> Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph
>> Cuis-Smalltalk-Ropes/Ropes.pck.st:	self changed: #actualContents!
>> !
>> Cuis-Smalltalk-Ropes/Ropes.pck.st:	self changed: #refetched.
>> Cuis-Smalltalk-Unicode/UniCodes.pck.st:	self changed:
>> #actualContents! !
>> Cuis-Smalltalk-Unicode/UniCodes.pck.st:	self changed: #refetched.
>>
> Hi Ken,
>
> In #actualContents: there is "self changed: #actualContents" which seems reasonable.
>
> However, in #refetch there is "self changed: #refetch" which is perplexing because it looks
> like infinite recursion, but it must be OK because similar examples appear in Browser.
>
>   - Dan

Just look at senders of #refetched . (not refetch!) It is quite simple, 
actually.

To see a bit more on how lists are used, see references to 
PluggableListMorph. The second is #buildMorphicMessageCatList. See how 
it parametrizes the instance it builds. These methods that create 
various lists are quite similar, and all they do is to bind each list 
with a different aspect of the model. In this case, with 
#messageCategoryList. See implementors and senders. It is clear that the 
implementors are methods in models that answer (guess what!!!!) a list 
of message categories. When you look at senders senders, you can see 
that some are in the model, doing things like 'self changed: 
#messageCategoryList'. It is easy to see that this means that the list 
of message categories have changed, and anybody depending on that should 
update itself.

Now we have a detail that is not that obvious, and most likely the clue 
you need to understand this all. See implementors of #update: in 
PluggableListMorph and the other PluggableMorph classes. #update: 
compares the argument with the listGetter (or the appropriate ivar for 
each morph). So, when the model does 'self changed: 
#messageCategoryList', all dependent morphs get  message 'eachMorph 
update: #messageCategoryList'. And only those morphs that were 
configured to watch on this symbol with react.

As I said before, this is the changed/update mechanism in MVC in 
Smalltlk-80. Using #when:send:to: insted would lead to better code. But 
documenting the current state of the system is needed and important,

Cheers,
Juan Vuletich