This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Just Announce It Feed Title: Travis Griggs - Blog Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml Feed Description: This TAG Line is Extra Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Travis Griggs - Blog

With two and a half Announcement switches under the belt, I'm noticing something I like. Take the last entry for example. A "StatFeedbackLoop". It queries a data table from some hardware object. The data is rich enough, that it's worth balling up in its own "Stats" object. With the triggerEvent: implementation, it looked something like:

triggerNewStats
	self triggerEvent: #newStats with: self deltaStats

The simplest most straightforward approach to converting a triggerEvent path into an Announcement one, is to take the triggerEvent symbol name, make an Announcement subclass by the same name, add ivars for any with: arguments you need, and move on.

The thing is, why not go a step farther. Just make the "Stats" object an Announcement. Then the code changes to:

announceStats
	self announce: self deltaStats

This pattern of having the with: data become the announcement has happened a couple of times now. And I think it's cool. Really cool. And I can't put my finger on why. But it feels good. When you begin using Announcements, look to have your already existing objects becoming the Announcement.

<Philosophical>
It has begged the question, why have a special Announcement class at all? Why not just be able to announce: any sort of Object? The Announcement class is very lightweight. It has some helper methods which translate pretty directly to meta class queries. The point being, be renaming some Announcements methods, one could move most of them to Object and just go from there (this would of course go against the "unburden Object" philosophy.

The only real state that Announcement offers is the veto stuff. This might be considered a specialization of an Announcement type, rather than the canonical norm. Indeed the presence of isVetoable, and it's default response of false supports this.

In the end, I think everything might become TOO abstract, but it's an interesting thought.