One thing to consider here is that Announcements are much more of a 
pattern than a framework. I.e., all it takes is an announcer 
implementing #on:do: and #announce: and you're ready to go. Given that 
we have an event hierarchy for system events already, how about using 
just that?

It would mean that we implement suitable #on:do: and #announce: methods 
in SystemChangeNotifier and start implementing the proper event handlers 
in whichever place we feel like, perhaps start in SmalltalkImage as an 
example of use.

As we migrate away from the old usage, we can make more specific event 
kinds and get rid of all those awful tests like "(anEvent isRemoved and: 
[anEvent itemKind = SystemChangeNotifier classKind])" by replacing them 
by appropriately scoped events, i.e.,

SystemChangeNotifier uniqueInstance on: ClassRemoved do:[...].

This approach also preserves sufficient compatibility as we move forward 
since all the existing protocols would continue to work.

Cheers,
   - Andreas

On 8/31/2010 10:31 AM, Eliot Miranda wrote:
> Hi All,
>
>      I have just found out why some recent images of ours at Teleplace
> aren't logging doits; the system notifications are missing Smalltalk as
> a target.  If you look at senders of
> SystemChangeNotifier>>notify:ofAllSystemChangesUsing: in trunk you'll
> see the following three key senders (ignoring tests)
>
>      ChangeSet class>>newChanges:          - ensures change sets keep up
> to date with changes
>      Preferences class>>registerForEvents  - ensures prefs stay up to
> date when methods with preference method tags get added/removed
>      Utilities class>>startUp                        - ensures recent
> submissions are maintained
>
> SmalltalkImage is conspicuously absent, yet
>
> | | am |
> am := (SystemChangeNotifier uniqueInstance instVarNamed: 'eventSource')
> actionMap.
> am keys select:
> [:k| | e |
> (e := am at: k) isArray
> ifTrue: [e anySatisfy: [:seq| seq receiver == Smalltalk]]
> ifFalse: [e receiver == Smalltalk]]
> #(#protocolRenamedEvent: #methodModifiedEvent: #protocolAddedEvent:
> #categoryRemovedEvent: #expressionDoItEvent: #methodRemovedEvent:
> #classReorganizedEvent: #protocolModifiedEvent: #categoryModifiedEvent:
> #classRenamedEvent: #protocolRemovedEvent: #classRemovedEvent:
> #classAddedEvent: #categoryRenamedEvent: #classModifiedEvent:
> #methodRecategorizedEvent: #classCommentedEvent: #methodAddedEvent:
> #classRecategorizedEvent: #categoryAddedEvent:)
>
> | am |
> am := (SystemChangeNotifier uniqueInstance instVarNamed: 'eventSource')
> actionMap.
> am keys reject:
> [:k| | e |
> (e := am at: k) isArray
> ifTrue: [e anySatisfy: [:seq| seq receiver == Smalltalk]]
> ifFalse: [e receiver == Smalltalk]]
>
> #(#methodReorganizedEvent: #methodCommentedEvent: #methodDoItEvent:
> #categoryRecategorizedEvent: #methodRenamedEvent:)
>
> and there's the rub.  Why isn't Smalltalk a target of all events?  Why
> does it exclude #methodReorganizedEvent: #methodCommentedEvent:
> #methodDoItEvent: #categoryRecategorizedEvent: #methodRenamedEvent:?  Is
> this merely accident?
>
> I'm pretty sure that SmalltalkImage class>>startUp needs to ensure
> system notifications are up-to-date, but are the above exclusions
> missing for any reason?  It's kind of hard to figure out (see below).  I
> *think* that it should read
>
> SmalltalkImage class>>startUp
> "XXXX: This is broken. SmalltalkImage startUp happens quite late in the
> startup sequence; earlier startups may very well need the information
> about the endianness of the platform."
> EndianCache := nil.
> SystemChangeNotifier uniqueInstance notify: Smalltalk
> ofAllSystemChangesUsing: #event:
>
> but I thought I'd check with y'all.
>
> and finally when can we reimplement this entire mess using e.g.
> Anouncements, I mean:
>
> AbstractEvent>>eventSelector
>
> ^self class eventSelectorBlock value: itemKind value: self changeKind
>
> AbstractEvent class>>eventSelectorBlock
>
> ^[:itemKind :changeKind | itemKind, changeKind, 'Event:']
>
> Surely this is too direct and easy to understand ;)  I mean who /needs/
> senders and implementors to work?
>
> grrr....
> Eliot
>
>
>
>