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
