Port Announcements subset from Pharo to GemStone

[martinmcclure]

Sparkle depends on the basic features of Announcements, so this needs to be ported to GemStone. Pharo's implementation of Announcements has some advanced features that we don't currently need, and may never need, so I suggest not porting those at this time. They're a bit odd. I'll give some examples of needed and not-needed features later.

[dalehenrich]

Here's the Announcements package that is used by GLASS for the last 8 years ,,, There's a GemToGemAnnouncements class there as well ...

The package is in filetree format, but Rowan can read filetree and write tonel ... it is very likely that code depends upon a hondful of pharo compatibility messages ...

I've got a GsDevKit/T2F2T-Conversion from which the magic Rowan incantations to do the conversion can be extracted ... if needed ...

[martinmcclure]

Thanks, Dale. That sounds like a good starting point.

Examples of things we need:

• Announcement
• Announcer

• when:send:to:

Examples of things we could easily leave out:

• AnnouncementDeliveryConditions -- unconditional delivery is fine, at least for now.

Comments:

• All announcement-related classes can be instancesNonPersistent. They don't need to persist, and I don't want to have to deal with them changing states at an abort.
• Weak subscriptions is a nice-to-have. I'm not using it currently, but my current code is probably leaking memory as a result. Weakness is handled differently in Pharo and GemStone. We have ephemerons in GemStone. There are some examples of ephemeron use in RSR.

[dalehenrich]

Announcements are used by GLASS via a SystemChangeNotifier class that is kept in session temps ... probably for the same things that you will be using them for (class and method changes) so we want to make sure that we don't break GLASS when we add announcements to the base ... AnnouncementDeliveryConditions didn't exist at the time of the port and the other things are present (IIRC)...

Here's a list of the GLASS methods that reference the SystemChangeNotifier class:

Behavior>>_announceMethodMoved:oldCategory:
Behavior>>_announceReorganized
Behavior>>_basicRemoveSelector:environmentId:
Behavior>>compileMethod:category:using:environmentId:
Behavior>>moveMethod:toCategory:
Behavior>>recompile:
Behavior>>removeEmptyCategories
 Class class>>_defineClassNamed:with:
 Class>>category:
 Class>>classComment:stamp:
 Class>>removeFromSystem
GsDeployerTest>>runCase
MCBrowser>>register
MCBrowser>>unregister
MCClassDefinition>>createClass
MCClassDefinition>>load
MCPackageManager class>>registerForNotifications
MetacelloGemStonePlatform class>>registerForNotifications
MethodVersionTest>>runCase
OBCodeBrowser>>register
OBCodeBrowser>>unregister

[martinmcclure]

Good to know. The initial Sparkle use of announcements is communication between layers. System change announcements will be useful once we move from debugging tools to coding tools.

[martinmcclure]

Richard's work merged to development.