How about statefull Traits?
http://scg.unibe.ch/archive/papers/Berg07aStatefulTraits.pdf

On 2013-07-20, at 12:48, Denis Kudriashov <dionisiydk@gmail.com> wrote:
> Hi
>
> 2013/7/19 Igor Stasenko <siguctua@gmail.com>
>
>> So, on your place, if you really need a lot of classes with announcer
>> capabilities, you can do it like that:
>>
>> Object subclass: #ObjectWithAnnouncer
>> instvars: 'announcer'
>>
>>
> ObjectWithAnnouncer is exactly what I think about Announcer. I just need
> class which makes my objects events sources. And I'm wondering why
> Announcer is bad for this?
> Just look at Announcer definition:
>
> Object subclass: #Announcer
>
> instanceVariableNames: 'registry'
>
> classVariableNames: ''
>
> poolDictionaries: ''
>
> category: 'Announcements-Core'
>
>
> "registry" variable is instance of SubscriptionsRegistry which actually
> implements all announcements logic. Announcer just adds convenient public
> api to events subscriptions and delivering. No complex logic. No actual
> knowledge about how announcements work.
> And your argument "why you subclass from Announcer" looks to me like why
> you subclass from SubscriptionsRegistry. But I'm not. Nobody doing it.
> So i'm not understand why you want another wrapper around Announcer.
>
> (To me "subscriptions" is better name then "registry". And I prefer
> composition than inheritance too).
>
>
>
>> then may implement same protocol as in Announcer in it, which will
>> simply delegate to announcer ivar.
>> And i bet, you don't want to expose full Announcer protocol there,
>> while probably you may want to implement some convenience protocols,
>> which Announcer lacking.
>>
>> So, at the end by subclassing from ObjectWithAnnouncer you will be
>> reusing its capabilities in each and every subclass of it, but by
>> delegating real job, you are free from worrying about dealing with
>> implementation detail and exposing unwanted state/protocols to its
>> users.
>>
>> Another aspect of it, is when i see:
>>
>> ObjectWithAnnouncer subclass: #MyDomainObject
>>
>> it tells me, aha.. so some (at least this one) of his domain objects
>> having announcers,
>> and the valid protocols is defined in ObjectWithAnnouncer.
>>
>> but when i see
>>
>> Announcer subclass: #MyDomainObject
>>
>> i starting to be uncertain: is Announcer private there or public?
>> can i send messages like #basicSubscribe: to your domain object and expect
>> that
>> it will be handled correctly? Or do i allowed to subscribe directly at
>> all, because maybe
>> domain object has some specific protocol(s) and ways to do that..
>> Every such question and uncertainty for coder means more time, more
>> errors, and less productivity.
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>