[Cuis] PluggableListMorph

[Dan Norton]

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