Hi henrik What you see is my mistake, I did not get the time to review to code of Spec. Now we should fix it. A while ago I sent a report about the number of Announcers. Now we need help to clean Spec because we are all fully juggling with other duties. I would like to come up with a roadmap. Any suggestions for a roadmap is welcome. I would like to reduce the API - remove as many as "whenChangedDo:" as possible. - revisit announcers because I do not see why the composableModel could not hold the announcer used by the valueHolders and then be shared. Stef Le 15/12/14 13:00, Henrik Johansen 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).
Cheers, Henry