November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/1 Tudor Girba <tudor.girba(a)gmail.com>: > Indeed, the main and only goal of Announcement is to provide an object- > oriented (Exception-like) way to handle notifications. > > I have used the Announcements implementation of Lukas on several > occasions and I did not feel the need for anything else. > > You indeed should subclass Announcement for any specific announcement, > but that is not a drawback, it is a nice feature. If you want to have > an announcement that you want to identify by a special single field, > you are free to implement that in one announcement class on top. > Thanks Doru. Indeed, its a feature, but not a rule which everyone should follow. In other thread, I had proposed to use field to identify an event type instead of class, and someone said that i'm doing it wrong. While i thinking that the way how the framework identifies events kinds (by default) not always best one, and as i illustrated its not good for everything. > Cheers, > Doru > > > On 1 Nov 2009, at 17:08, Lukas Renggli wrote: > >>> Obviously i can't. Because if i make all of the tree to be a subclass >>> of LoggedAnnouncement, then all of them >>> will be logged, while i want only some of them. >> >> You are missing the point of announcements: they are not supposed to >> do anything, they are only supposed to notify interested parties about >> something. It is the sole responsibility of the interested party to >> register for announcements. If somebody is interested logging some >> announcement, then this interested party should declare that wish. The >> announcement itself shouldn't care. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 1, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/1 Lukas Renggli <renggli(a)gmail.com>: >> Obviously i can't. Because if i make all of the tree to be a subclass >> of LoggedAnnouncement, then all of them >> will be logged, while i want only some of them. > > You are missing the point of announcements: they are not supposed to > do anything, they are only supposed to notify interested parties about > something. It is the sole responsibility of the interested party to > register for announcements. If somebody is interested logging some > announcement, then this interested party should declare that wish. The > announcement itself shouldn't care. > Hmm.. i don't think that i'm missing the point. Where in this code: annoucer on: LoggedAnnouncement do: [:ann | Transcript show: ann message ]. you see that i'm putting a responsibility for handling the announcement on announcement, instead of subscriber? Subscriber provides a block, and given that LoggedAnnouncement implements #message , it simply using it. But subscriber is free to do anything he likes to in the handler block, so again, i don't see where i putting any responsibility on announcement instead of subscriber. Oh, wait.. you mean that if i want, say 35 out of 50 announcement kinds to be logged, then i need to do something like: logblock := [:announcement | ... ]. announcer on: AnnouncementKind1 do: logblock. announcer on: AnnouncementKind2 do: logblock. .... announcer on: AnnouncementKind35 do: logblock. ? Do you agree that this is far from being short and elegant? Moreover it imposes dependency from various kinds of events, instead of just one (LoggedAnnouncement), and, if i going to change them somehow, i would need to revisit this code again.. and again. I used this case to illustrate, that single inheritance , which used in Annoucements framework not always sufficient. In this case, it would need to overrride Announcement class>>handles: anAnnouncementClass ^ anAnnouncementClass isKindOf: self in LoggedAnnouncement , to something like: LoggedAnnouncement class>>handles: anAnnouncementClass ^ anAnnouncementClass isLoggedAnnouncement and provide a default #isLoggedAnnouncement implementation in Announcement class. as well as in any my own classes, override it to answer true. So, to implement this scenario i need substantional efforts to be taken. And already will need to extend Announcement class. > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 1, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Tudor Girba

Indeed, the main and only goal of Announcement is to provide an object- oriented (Exception-like) way to handle notifications. I have used the Announcements implementation of Lukas on several occasions and I did not feel the need for anything else. You indeed should subclass Announcement for any specific announcement, but that is not a drawback, it is a nice feature. If you want to have an announcement that you want to identify by a special single field, you are free to implement that in one announcement class on top. Cheers, Doru On 1 Nov 2009, at 17:08, Lukas Renggli wrote: >> Obviously i can't. Because if i make all of the tree to be a subclass >> of LoggedAnnouncement, then all of them >> will be logged, while i want only some of them. > > You are missing the point of announcements: they are not supposed to > do anything, they are only supposed to notify interested parties about > something. It is the sole responsibility of the interested party to > register for announcements. If somebody is interested logging some > announcement, then this interested party should declare that wish. The > announcement itself shouldn't care. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Some battles are better lost than fought."

Nov. 1, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Lukas Renggli

> Obviously i can't. Because if i make all of the tree to be a subclass > of LoggedAnnouncement, then all of them > will be logged, while i want only some of them. You are missing the point of announcements: they are not supposed to do anything, they are only supposed to notify interested parties about something. It is the sole responsibility of the interested party to register for announcements. If somebody is interested logging some announcement, then this interested party should declare that wish. The announcement itself shouldn't care. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 1, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/1 Igor Stasenko <siguctua(a)gmail.com>: > 2009/11/1 Lukas Renggli <renggli(a)gmail.com>: >>> But if it so stripped to bare-bones, then where the benefits to use >>> exactly Announcements? >> >> I would rather like to hear what this "more wide functionality" is all about? >> > > i don't know. I just not buying 'use this' because its good. I need to > know why its so good :) > As far as i can see, it is as good as any other observer pattern implementation. > But alone, this pattern is nothing, so we should analyze, how well it > fits for use in different scenarios. > And so, what if such implementation doesn't play well with all > scenarios, would you still insist > to use Announcements instead of making own, given that cost of > implementation is quite small (10 or even less methods)? > >> So far you only argued that big is better. I don't buy that. >> > In contrary. An annoucements implies to use separate (sub)classes for > different event kinds. > While i can simply use field in the event to identify its kind. > Lets say you having 50 event kinds. So what is bigger - single class + 1 field, > or 50 classes? Or we not counting classes as a code? > > So, as you can see, announcements, in some cases could lead to > 'bigger' code bloat. > And i would like to know, why it is still good to use them, despite > the costs of such potential bloat. > Just a bit more arguing. :) Suppose i bought the idea, and created a 50 subclasses. They form some kind of tree (such as AbstractEvent subclasses). So far so good. But now i want some of those event kinds to be logged, while some of them are not. What annoucements framework could propose for this scenario? Okay, i can create a new announcement subclass: Announcement subclass: #LoggedAnnouncement ... so then any , who would like to subcscibe to logged announcement could simply do something like: annoucer on: LoggedAnnouncement do: [:ann | Transcript show: ann message ]. But how i suppose to wire it up with the tree above? Obviously i can't. Because if i make all of the tree to be a subclass of LoggedAnnouncement, then all of them will be logged, while i want only some of them. >> This is old, but "Small is the new big" ;-) >> >> A smaller infrastructure also means: >> >> - easier to learn >> - less code that rots >> - less code to maintain >> - less code duplication >> - less code to test >> - loose coupling >> - smaller image >> > yes, good software is one where nothing left to remove, instead > nothing left to add. > > >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Nov. 1, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

2009/11/1 Lukas Renggli <renggli(a)gmail.com>: >> But if it so stripped to bare-bones, then where the benefits to use >> exactly Announcements? > > I would rather like to hear what this "more wide functionality" is all about? > i don't know. I just not buying 'use this' because its good. I need to know why its so good :) As far as i can see, it is as good as any other observer pattern implementation. But alone, this pattern is nothing, so we should analyze, how well it fits for use in different scenarios. And so, what if such implementation doesn't play well with all scenarios, would you still insist to use Announcements instead of making own, given that cost of implementation is quite small (10 or even less methods)? > So far you only argued that big is better. I don't buy that. > In contrary. An annoucements implies to use separate (sub)classes for different event kinds. While i can simply use field in the event to identify its kind. Lets say you having 50 event kinds. So what is bigger - single class + 1 field, or 50 classes? Or we not counting classes as a code? So, as you can see, announcements, in some cases could lead to 'bigger' code bloat. And i would like to know, why it is still good to use them, despite the costs of such potential bloat. > This is old, but "Small is the new big" ;-) > > A smaller infrastructure also means: > > - easier to learn > - less code that rots > - less code to maintain > - less code duplication > - less code to test > - loose coupling > - smaller image > yes, good software is one where nothing left to remove, instead nothing left to add. > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 1, 2009

Re: [Pharo-project] [update 1.1] #11020

by StÃ©phane Ducasse

ok I should have fixed it now. Stef On Nov 1, 2009, at 1:16 PM, StÃ©phane Ducasse wrote: > I rollback 11020 and I will redo it after lunch > Stef > > On Oct 31, 2009, at 11:38 PM, Nicolas Cellier wrote: > >> What is RPackage ? >> It seems to cause a failure during upgrade >> >> 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> nicolas >>> >>> could you check because I have some tests that fail on Float. >>> >>> stef >>> On Oct 31, 2009, at 8:49 PM, StÃ©phane Ducasse wrote: >>> >>>> 11020 >>>> ----- >>>> >>>> - Issue 1387: Mantis 7409 arcTan: has a specific implementation >>>> near >>>> zero and negativeZero >>>> Test and patch for http://code.google.com/p/pharo/issues/detail?id=1387 >>>> http://bugs.squeak.org/view.php?id=7409 >>>> make arcTan: behave like libm atan2 near zero and negativeZero >>>> >>>> - Issue 1390: Print literals exactly when decompiled >>>> >>>> - Issue 1388: FixedIdentitySet #arraySize has no senders >>>> >>>> - Issue 1331: DNU upon file-in of changeset >>>> >>>> >>>> stef >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 1, 2009

Re: [Pharo-project] [update 1.1] #11020

by StÃ©phane Ducasse

I rollback 11020 and I will redo it after lunch Stef On Oct 31, 2009, at 11:38 PM, Nicolas Cellier wrote: > What is RPackage ? > It seems to cause a failure during upgrade > > 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> nicolas >> >> could you check because I have some tests that fail on Float. >> >> stef >> On Oct 31, 2009, at 8:49 PM, StÃ©phane Ducasse wrote: >> >>> 11020 >>> ----- >>> >>> - Issue 1387: Mantis 7409 arcTan: has a specific implementation near >>> zero and negativeZero >>> Test and patch for http://code.google.com/p/pharo/issues/detail?id=1387 >>> http://bugs.squeak.org/view.php?id=7409 >>> make arcTan: behave like libm atan2 near zero and negativeZero >>> >>> - Issue 1390: Print literals exactly when decompiled >>> >>> - Issue 1388: FixedIdentitySet #arraySize has no senders >>> >>> - Issue 1331: DNU upon file-in of changeset >>> >>> >>> stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 1, 2009

Re: [Pharo-project] Print all Array either as literal form #( ... ) or brace form { ... } and abandon the default form anArray( ... )

by StÃ©phane Ducasse

probably. Stef On Nov 1, 2009, at 11:43 AM, Nicolas Cellier wrote: > OK, then the selfEvaluatingForm should better send storeOn: in order > to handle parenthesis problems. > > Nicolas > > 2009/11/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi nicolas >> >> I saw the following: >> Print all Array either as literal form #( ... ) or brace >> form { ... } >> and abandon the default form anArray( ... ) >> >> Now I recall why I introduced anArray (....) for printing. >> This is for case where the { . } does not work. >> >> Imagine that you have an object that does not have a printing version >> >> The key point of the design of self evaluating was that you could >> select an expression ie >> >> {10@20 . 30@20} and print it and get the same object >> this way we could manipulate a lot of objects much better in an >> inspector or debugger. >> >> So if we { anObjectWithAWrongForm . 10@20} it defeats the purpose of >> self evaluating. >> since there are situations like that anyway this is why we decided to >> have anArray( ....) to really indicate >> that this could not be self evaluating. >> >> The form #() and {} on the other sides where always something that we >> could manipulate. >> so I had the impression that fixing some classes would be nicer than >> removing the distinction. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 1, 2009

Re: [Pharo-project] Print all Array either as literal form #( ... ) or brace form { ... } and abandon the default form anArray( ... )

by Nicolas Cellier

OK, then the selfEvaluatingForm should better send storeOn: in order to handle parenthesis problems. Nicolas 2009/11/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi nicolas > > I saw the following: > Â Â Â Â Print all Array either as literal form #( ... ) or brace form { ... } > and abandon the default form anArray( ... ) > > Now I recall why I introduced anArray (....) for printing. > This is for case where the { . } does not work. > > Imagine that you have an object that does not have a printing version > > The key point of the design of self evaluating was that you could > select an expression ie > > {10@20 . 30@20} and print it and get the same object > this way we could manipulate a lot of objects much better in an > inspector or debugger. > > So if we { anObjectWithAWrongForm . 10@20} it defeats the purpose of > self evaluating. > since there are situations like that anyway this is why we decided to > have anArray( ....) to really indicate > that this could not be self evaluating. > > The form #() and {} on the other sides where always something that we > could manipulate. > so I had the impression that fixing some classes would be nicer than > removing the distinction. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2009