[Cuis] PluggableListMorph

[Dan Norton]

On 23 Oct 2015 at 13:59, Juan Vuletich wrote:

> 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. 

Ah. That's the key - I haven't looked at MVC in years. The model need not know about any 
view. It is the dependee, signalling happenings that the dependents might like to know. What 
dependents do starts with their #update: message which may take action after looking at the 
parameter (or not). The views are dependents of the model.

It's misleading when parameters of #changed: look just like message selectors in the model. 
It gives the impression that those messages are to be sent or invoked, when all that's 
necessary is that the parameter be understood by the model. That is why it looks like infinite 
recursion when a method says: 

refetched
	...
	self changed: #refetched.

Far better if the parameter was "foobar or #putDataInTheTextMorphs or the like.

> Using #when:send:to: insted would lead to better code.

I will definitely start doing that.

> But 
> documenting the current state of the system is needed and
> important,

With this insight, I may be able to do that now.

 - Dan