Andreas Raab wrote:
> Hi -
> 
> Thanks to everyone for all the info on announcements. For reference, I'd 
> say the canonical URL is this one (as it links to the whole serious of 
> posts about the topic):
> 
> http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Announcements%20Framework 
> 
> 
> I spent quite a bit of the weekend playing with Announcements and I like 
> it even more now. One thing that convinced me is that it is almost more 
> like a pattern than a framework - you can implement it with minimal 
> effort (I did it just by writing about 100loc total) but grow it to suit 
> ones needs[1].
> 
> [1] One of the things I quickly found was that I wanted the subscription 
> from #on:send:to: returned in order to be able to control whether it is 
> client-owned (weak for the signaler) or not. Turned out that this is 
> really just a minor modification which fits the model just fine.
> 
> One thing I am wondering about is whether anyone out there has been 
> using Announcements for frameworks that have a larger number of events. 

I'm using Announcements with my webapp and I have 40 classes and about
25 distinct events.
No problem until now either in performance or in code readability. Also, 
the fact that the announcement can convey real objects it is really the 
best thing of anything.

Miguel Cobá


> The framework I applied it to ended up with some 30 events (the total 
> number of classes in the framework is about 70, but it is event-heavy) 
> which at first seemed excessive but it *is* the number of events that 
> are being used so at least people can find out whether there is an event 
> for a change of foo or not. In that sense my original intuition proved 
> true (lots of classes but you do get to document the events in your 
> system). I am curious how people feel about this proliferation of classes.
> 
> The other thing that using Announcements extensively will probably force 
> is name spaces. It seems impossible for two frameworks not to have a 
> "ValueChanged" event. The precise definition of which will likely differ 
> (for example, where I've been using it, it is critical that the signaler 
> gets passed along with it; but I am certain there are some places where 
> people don't want to pay for that slot).
> 
> In any case, I think announcements are a great improvement over the 
> usual pattern of using event names instead of objects. You should 
> definitely give it a try the next time you consider using an event 
> framework.
> 
> Cheers,
>   - Andreas
> 
> Keith Hodges wrote:
>> Andreas Raab wrote:
>>> Damien Cassou wrote:
>>>> On Fri, Feb 27, 2009 at 5:24 PM, Andreas Raab <andreas.raab at gmx.de>
>>>> wrote:
>>>>> Does anyone have a canonical site for Announcements handy? Is there
>>>>> a Squeak
>>>>> implementation?
>>>> http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&printTitle=Introducing_Announcements&entry=3310034894 
>>>>
>>>>
>>>>
>>>> http://source.lukas-renggli.ch/announcements.html
>>> Wow. That is really nice. I was just playing with it and two things
>>> struck right away: How nice it is to be able to cross-reference events
>>> via Cmd-Shift-N (references to class) without being distracted by
>>> message names used to handle an event of the same name (i.e., self on:
>>> #mouseDown send: #mouseDown to: aMorph). Secondly, there is finally a
>>> way of documenting event types implicitly! (i.e., no more browse all
>>> senders of #signal: and try to see if there's one that looks about 
>>> right)
>>>
>>> Looks like a prime candidate for a nice little BPP[1] to me ;-)
>>>
>>> Cheers,
>>>   - Andreas
>> see also:
>>
>> http://lists.squeakfoundation.org/pipermail/seaside/2008-April/017540.html 
>>
>>
>> as part of the thread:
>>
>> http://lists.squeakfoundation.org/pipermail/seaside/2008-April/017417.html 
>>
>>
>> Keith
>>
>>
>>
>>
> 
> 
>