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

[Pharo-project] [update 1.1] #11022

by StÃ©phane Ducasse

11022 ----- Part of : Issue 500: [Pending Etoy Cleaning] Morph>>player

Nov. 1, 2009

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

by Igor Stasenko

2009/11/1 Yoshiki Ohshima <yoshiki(a)vpri.org>: > At Sun, 1 Nov 2009 19:35:57 +0200, > Igor Stasenko wrote: >> >> 2009/11/1 Lukas Renggli <renggli(a)gmail.com>: >> >> 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. >> > >> > Â Â announcer >> > Â Â Â Â on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35 >> > Â Â Â Â do: logblock >> > >> good catch. >> Still dependency on 35 classes .. while my intent is to subscribe to >> all announcements which can be logged. >> If i load new package, it could provide more announcements which can be logged. >> But i will not be able to see them if i'm going to enumerate them in >> such way :( > > Â If "can be logged" means to have #canBeLogged method that returns > true, you could also say (given that you provide a default > implementation of #canBeLogged at a/the root): > > logblock := [:announcement | announcement canBeLogged ifTrue: [... ]]. > announcer on: Announcement do: logblock. > i dont want to nitpick , but since you subscribing to the Announcement class, this means that you need to put an extension method #canBeLogged into it. And we started this discussion from question: is Announcements framework is generic enough and won't require more coding. But extending it is already means 'more code' in base. > Loading a package with new subclasses of Announcement is not a > problem. Â And, a recipient ignoring an announcement that it doesn't > handle is somewhat common, when I used my own implementation for my > projects. > > Â If you implement an observer pattern to accommodate the new package > loading requirement, what would be the strategy to implement it? > Not necessarily a new package. The problem is, that i don't want to modify multiple places in system if i reconsider whether something can be logged or not, as well as i want to be sure that my code will handle all and any potential changes in future without the need of any modifications in my code. I think that this part of discussion can be closed. Another question , which Stephane noted already, is the overhead of broadcasting. In Announcer>>announce: it iterating over all subscriptions to determine which one may want to receive an announcement or not. subscriptions keysAndValuesDo: [ :class :actions | (class handles: announcement) ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ]. but if we can't avoid iteration, then why ASKING but not TELLING to handle it: subscriptions do: [ :subscriber | subscriber handle: announcement ]. (subscriptions collection can be just a Set in this case) and then , a particular subscriber could decide whether he interested in given announcement or not, based on own criteria (such as #canBeLogged etc). And surely, we can provide a subscriber class, which can use the same logic, to determine if it interested in particular announcement, based on announcement class. This could make the whole thing more flexible. > -- Yoshiki > > _______________________________________________ > 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

[Pharo-project] [update 1.1] #11021

by StÃ©phane Ducasse

11021 ----- Issue 475: [Pending Etoy Cleaning] Object>>presenter

Nov. 1, 2009

[Pharo-project] about Issue 860: Accelerate MulitByteFileStream

by StÃ©phane Ducasse

nicolas do you have an idea how I could integrate these changes. I could not really understand what andreas meant when he pushed them into their trunk Stef

Nov. 1, 2009

[Pharo-project] apparently we do not find classes when in array

by StÃ©phane Ducasse

for example try apple-N for Presenter you will not find the references in rootsIncludingPlayers... Can somebody allocate time to fix that because this is important. Issue 1394: Not getting some class references http://code.google.com/p/pharo/issues/detail?id=1394 Stef

Nov. 1, 2009

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

by Yoshiki Ohshima

At Sun, 1 Nov 2009 19:35:57 +0200, Igor Stasenko wrote: > > 2009/11/1 Lukas Renggli <renggli(a)gmail.com>: > >> 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. > > > > Â Â announcer > > Â Â Â Â on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35 > > Â Â Â Â do: logblock > > > good catch. > Still dependency on 35 classes .. while my intent is to subscribe to > all announcements which can be logged. > If i load new package, it could provide more announcements which can be logged. > But i will not be able to see them if i'm going to enumerate them in > such way :( If "can be logged" means to have #canBeLogged method that returns true, you could also say (given that you provide a default implementation of #canBeLogged at a/the root): logblock := [:announcement | announcement canBeLogged ifTrue: [... ]]. announcer on: Announcement do: logblock. Loading a package with new subclasses of Announcement is not a problem. And, a recipient ignoring an announcement that it doesn't handle is somewhat common, when I used my own implementation for my projects. If you implement an observer pattern to accommodate the new package loading requirement, what would be the strategy to implement it? -- Yoshiki

Nov. 1, 2009

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

by Igor Stasenko

2009/11/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > you see you find a use of Set :) > IMO, this is a find where you should not use Set :) > Stef > > On Nov 1, 2009, at 6:17 PM, Lukas Renggli wrote: > >>> 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. >> >> Â Â announcer >> Â Â Â Â on: AnnouncementKind1 , AnnouncementKind2 , ... >> AnnouncementKind35 >> Â Â Â Â do: logblock >> >> -- >> 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 > > > _______________________________________________ > 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>: >> 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. > > Â Â announcer > Â Â Â Â on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35 > Â Â Â Â do: logblock > good catch. Still dependency on 35 classes .. while my intent is to subscribe to all announcements which can be logged. If i load new package, it could provide more announcements which can be logged. But i will not be able to see them if i'm going to enumerate them in such way :( > -- > 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 StÃ©phane Ducasse

you see you find a use of Set :) Stef On Nov 1, 2009, at 6:17 PM, Lukas Renggli wrote: >> 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. > > announcer > on: AnnouncementKind1 , AnnouncementKind2 , ... > AnnouncementKind35 > do: logblock > > -- > 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

Nov. 1, 2009

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

by Lukas Renggli

> 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. announcer on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35 do: logblock -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 1, 2009