Certainly :) Doru
On Sat, Jul 20, 2013 at 1:48 PM, Camillo Bruni <camillobr...@gmail.com>wrote: > How about statefull Traits? > http://scg.unibe.ch/archive/papers/Berg07aStatefulTraits.pdf > > > On 2013-07-20, at 12:48, Denis Kudriashov <dionisi...@gmail.com> wrote: > > Hi > > > > 2013/7/19 Igor Stasenko <siguc...@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. > >> > >> > > > -- www.tudorgirba.com "Every thing has its own flow"
