Hi Tim,
I don't have a squeak image handy so this comes a bit out of thin air,
but i recall having posted a very similar "optimization" for the
morphic package pane browser where i explicitly relied on the
method comments in SystemOrganization.
There it is stated somewhere that whenever a change to the list
structure happens, the list instance is replaced also to make the
update mechanism work.
If i don't hear anything from you i will dig up the exact mehtods and
comments and my original post tomorroe.

HTH,
Torge
----- Original Message -----
From: "Tim Rowledge" <tim at sumeru.stanford.edu>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, October 15, 2002 8:18 PM
Subject: Re: [BUG]Who removed handling of 'changed: #messageList'?


> Bob Arning  <arning at charm.net> is claimed by the authorities to have
written:
>
> > IMO, what _should_ be handling it is PluggableListView>>update: where
getListSelector matches #messageList. Either it did not get set as a
dependent or it's just doing the wrong thing.
> After spending some time tracing through, it's all set up ok for
> dependents etc; the 'culprit' is in PluggableListView>list: where the
> first thing done is to check to see if the incoming list of items is
> that same object as the currently cached list of items. For _any_
> application where the list is being added to etc this is a complete
> failure case - you add something (or remove something, or replace
> something) and the list Paragraph will not be updated. So either the
> 'optimisation' needs to do something nearer to checking the incoming
> list against the list in the Paragraph, or it needs to become a well
> known invariant that the collection must not be cached by the
> application. Or something else.
>
>
> Unfortunately if you comment out this 'optimisation' you get the
> multiple updates  tango as well as some odd cases where the list
> background goes white. (hmm, odd thing here later while checking
> something, it doesn't seem to happen now. )
>
> Oh, and there are some very odd things that happen to the tracing
> browser where it appears that the  MessageSet's methodListIndex is ok at
> the beginning of TracingMessageBrowser>
> addChildMessages:autoSelectString: but 0 by the second 'sentence'. Which
> causes another whole chain of debugger fun that I don't have timeto play
> with right now.
>
> The signature on the #list:  methods is Dan's dating from last june or
> so.
>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: BPB: Branch on Program Bug
>
>