July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About abuse of inheritance

by Denis Kudriashov

2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Interesting how many people in this list think that "Announcer subclass: > #TxEditor" provides special implementation of announcer named TxEditor? > > > Many > this is composition using inheritance and inheritance should not be used > like that. > > Announcer subclass: #GreedyAnnouncer > > Announcer subclass: #RemoteAnnouncer > And if we prefer composition we should not implement such kind of hierarchy. We should implement GreadySubscriptionsRegistry, RemoteSubscriptionsRegistry or AsynchSubscriptionsRegistry and reuse existed Announcer. All subscribing and delivering logic implemented by subscription registry. Announcer is just simple delegator with convenient api to create Subscription instances: Announcer>>subscribe: anAnnouncementClass do: aValuable "Declare that when anAnnouncementClass is raised, aValuable is executed." ^ registry add: ( AnnouncementSubscription new announcer: self; announcementClass: anAnnouncementClass; valuable: aValuable) Announcer>>announce: anAnnouncement | announcement | announcement := anAnnouncement asAnnouncement. registry ifNotNil: [ registry deliver: announcement ]. ^ announcement All magic happens inside #add: and #deliver: methods of SubscriptionsRegistry. Also announcements framework provides very nice feature: you can have announcer as last argument of event handler selector (that's why AnnouncementSubscription contains reference to announcer instance): announcer on: MyEvent send: #handleAnnouncement:raisedBy: to: aSubscriber Without subclassing YourEventsSource from Announcer you will not have such feature. Or you will need implement complex subscription method inside YourEventSource which will delegates special event handler to its announcer

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by StÃ©phane Ducasse

On Jul 21, 2013, at 7:30 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Though, Dictionary was technically a Set of Associations, yes but API(DICTIONARY) is not the same as API(SET) => ARGHHHHHHHHHHHHHHHHH > until someone changed Association>>= to also compare values. subclassing does not mean that technically it is wrong. subclassing is reuse so reuse is happening but at the cost of bending APIs and killing the poor maintainers with yyy ^ super xxx and should not understand. Stef > > > 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jul 21, 2013, at 5:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> 2013/7/21 Igor Stasenko <siguctua(a)gmail.com> >> Yes, but where are the guarantees that you don't? >> Just think from outsider's point of view: when he sees >> >> Announcer subclass: #Foo >> >> what he will think first: >> - aha, this guy implements own kind of announcer >> or >> - aha this guy reusing announcer >> or >> - aha, this guy doing both things at the same time (a worst possible >> alternative) >> >> and how many abuses like that, he should see before making a logical conclusion: >> - aha.. this is the way how i should do as well. >> >> Interesting how many people in this list think that "Announcer subclass: #TxEditor" provides special implementation of announcer named TxEditor? > > Many > this is composition using inheritance and inheritance should not be used like that. > > Announcer subclass: #GreedyAnnouncer > > Announcer subclass: #RemoteAnnouncer > > Are quite different from > > Announcer subclass: #Customer > > This is not because subclassing can be used that we should do it. > We suffer during years from > Dictionary subclass: #Set > and other beauties. > > > > >> Because to me it is not practical design issues when we talk about subclassing Announcer. >> > >

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Nicolas Cellier

Though, Dictionary was technically a Set of Associations, until someone changed Association>>= to also compare values. 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jul 21, 2013, at 5:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > 2013/7/21 Igor Stasenko <siguctua(a)gmail.com> > >> Yes, but where are the guarantees that you don't? >> Just think from outsider's point of view: when he sees >> >> Announcer subclass: #Foo >> >> what he will think first: >> - aha, this guy implements own kind of announcer >> or >> - aha this guy reusing announcer >> or >> - aha, this guy doing both things at the same time (a worst possible >> alternative) >> >> and how many abuses like that, he should see before making a logical >> conclusion: >> - aha.. this is the way how i should do as well. >> > > Interesting how many people in this list think that "Announcer subclass: > #TxEditor" provides special implementation of announcer named TxEditor? > > > Many > this is composition using inheritance and inheritance should not be used > like that. > > Announcer subclass: #GreedyAnnouncer > > Announcer subclass: #RemoteAnnouncer > > Are quite different from > Announcer subclass: #Customer > > This is not because subclassing can be used that we should do it. > We suffer during years from > Dictionary subclass: #Set > and other beauties. > > > > > Because to me it is not practical design issues when we talk about > subclassing Announcer. > > >

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by StÃ©phane Ducasse

On Jul 21, 2013, at 6:39 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Sun, Jul 21, 2013 at 12:10 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> May be we should refactor the code so that we can specify if the warning should be raised >> or not. > > > this happens at startup. Do you have an idea in mind? Should I add an > instance variable for that? why not? Let us use our tool to tame complexity. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by StÃ©phane Ducasse

On Jul 21, 2013, at 5:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/7/21 Igor Stasenko <siguctua(a)gmail.com> > Yes, but where are the guarantees that you don't? > Just think from outsider's point of view: when he sees > > Announcer subclass: #Foo > > what he will think first: > - aha, this guy implements own kind of announcer > or > - aha this guy reusing announcer > or > - aha, this guy doing both things at the same time (a worst possible > alternative) > > and how many abuses like that, he should see before making a logical conclusion: > - aha.. this is the way how i should do as well. > > Interesting how many people in this list think that "Announcer subclass: #TxEditor" provides special implementation of announcer named TxEditor? Many this is composition using inheritance and inheritance should not be used like that. Announcer subclass: #GreedyAnnouncer Announcer subclass: #RemoteAnnouncer Are quite different from Announcer subclass: #Customer This is not because subclassing can be used that we should do it. We suffer during years from Dictionary subclass: #Set and other beauties. > Because to me it is not practical design issues when we talk about subclassing Announcer. >

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by Damien Cassou

On Sun, Jul 21, 2013 at 12:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > May be we should refactor the code so that we can specify if the warning should be raised > or not. this happens at startup. Do you have an idea in mind? Should I add an instance variable for that? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by Damien Cassou

On Sun, Jul 21, 2013 at 10:18 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > SmalltalkImage checkChangesFileAvailability: false. Thank you Norbert, but this method does not exist -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Denis Kudriashov

2013/7/21 Igor Stasenko <siguctua(a)gmail.com> > Yes, but where are the guarantees that you don't? > Just think from outsider's point of view: when he sees > > Announcer subclass: #Foo > > what he will think first: > - aha, this guy implements own kind of announcer > or > - aha this guy reusing announcer > or > - aha, this guy doing both things at the same time (a worst possible > alternative) > > and how many abuses like that, he should see before making a logical > conclusion: > - aha.. this is the way how i should do as well. > Interesting how many people in this list think that "Announcer subclass: #TxEditor" provides special implementation of announcer named TxEditor? Because to me it is not practical design issues when we talk about subclassing Announcer.

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Denis Kudriashov

Hi Igor. 2013/7/21 Igor Stasenko <siguctua(a)gmail.com> > There are 3 kinds of roles in context: > > - subscriber: an object who subscribing for events to receive them later > - an event source (the object which announces the event) > - an announcer, an object which provides subscription service and > through which you can announce events, acting as mediator between 2 > parties above > > > the rest, like registry, Announcement (as class) and subscriptions is > implementation detail. > The main reason for using Announcements model is to have decoupling > between event source (the place/object , which producing events) and > its handlers. And announcer provides such decoupling. > I understand your position. But I think it is too little and simple place to introduce another object. And original paper about Announcements framework (maybe from Vasiliy Bykov) not described such distinction between event source and announcer as subscription service. Too me subscription service is exactly SubscriptionsRegistry. Interesting how Announcer used in VisualWorks system. Any way if we agree with your proposals we should add EventsSource class (choose better name) to Announcements package. And we should describe it in announcements chapter in pharo book. Because now there are no documentation where your distinction are explained and that's why now natural way to make event source classes is subclassing Announcer. Best regards, Denis

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by StÃ©phane Ducasse

On Jul 21, 2013, at 2:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Yes, but where are the guarantees that you don't? > Just think from outsider's point of view: when he sees > > Announcer subclass: #Foo > > what he will think first: > - aha, this guy implements own kind of announcer > or > - aha this guy reusing announcer + 1 Stef

July 21, 2013