Le 15 déc. 2014 13:00, "Henrik Johansen" <henrik.s.johansen@veloxit.no> a écrit :
I thought I'd fix a small bug following
https://pharo.fogbugz.com/f/cases/14604 , the DiffMorphChangeRecordConverters referenceList does not get updated to the new model's list when reverting a method, so after reverting, the left pane will always show (and compare against) the last version, rather than the previous from selected.
No problem, as per the discussion of Spec's excessive annoucement
wrapping/ValueHolder appetite, let's try do the simple thing and add a small Announcement subscription, essentially:
browser listModel announcer when: ValueChanged send: #updateReferences: to: aConverter.
<rant> To my surprise, that did not work. Hmmm, must be a different announcement then, ListChanged maybe. After all, it makes sense that a MultiSelectionInList has multiple events that subscribers might be interested in.
So I started looking at ListModel, <insert relevant explicits here>! There are, count them and weep, *32* different NewValueModels instance variables, each with different announcers.
In the case I was looking at, in addition to a listHolder inst var (a CollectionValueHolder), there's a listAnnouncer inst var (an Announcer), so just finding the one through which announcements are made is next to impossible (with the ListModel's own announcer, that's three different ones that would potentially make sense), at least without consulting the *offical* API; #whenListChanged:
Turns out, in the current implementation, listAnnouncer is the one I want. Which isn't exposed through an accessor, so you can't even use it to subscribe directly. Yay. </rant>
If someone has time to restructure this, I would like to suggest changing the internals radically; - Introduce new Announcement types for all the different Value holders that make sense (SelectionChanged, ListChanged), and drop the rest. I mean, whenSortingBlockChanged: ?? Who on earth would be interested in that, and not already respond to ListChanged (or it's current equivalent) - Reduce the amount of announcers to a saner number, say, 1 (or, in a pinch, 2).
Yeah there are "Announcement storms" going on with Spec based tools. I think that it explains a lot of the sluggishness of some tools, like Nautilus. I saw these when doing some Nautilus plug-ins for my own use (e.g. bring back the original senders/implementors... buttons). Squeak tools feel very very snappy in comparison. Even on a superfast PC, Pharo as some annoying delays. Announcements are great but overusing them is receipe for serious head scratching and does not lend itself to easy discoverability of how things do work. Phil Phil
Cheers, Henry