About AXAnnouncements (was: some Announcements related questions)
Locked
123
123
Re: About AXAnnouncements (was: some Announcements related questions)
 
|
> Igor, even if you open a shiny new Pharo image, I'm afraid you'll have > to contemplate plenty of ancient code. > Note sure the most ancient the most dusty though ;). > > FIY, st80 MVC was broadcasting to 99% of ignorers with a long chain of > this kind: > self changed: aSymbol SENT FROM THE MODEL > -> self changed:with: > --> self changed:with:from: > ---> update:with:from: BROADCAST IN EACH dependents (each subview was > potentially) > --> update:with: > -> update: > > I hope we don't replicate this scheme, I had understood Announcements > did not thanks to explicit subscription. as did the later versions in VW. SOrry that I raised this question. Typing too fast > Anyway, a bit of archeology is always helpfull when cleaning > Smalltalk... > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
In reply to this post by Igor Stasenko
>>
> Oh yeah, i seen that code, and Dependents class var in Object class, > which is a dictionary of dictionaries... > This model, as well as morphic extensions, takes roots from Self's > morphic, where you can easily extend > any object state by adding new slots to it. In smalltalk we don't have > dynamic named slots, and thus we > having such ugly crutches :) No it was before that. It was because any object could have a dependent (even if model was favored) so for object the registration was stored in a large table. >> I hope we don't replicate this scheme, I had understood Announcements >> did not thanks to explicit subscription. >> Anyway, a bit of archeology is always helpfull when cleaning >> Smalltalk... >> > > It is strange, i have a feeling that people think i am being > short-sighted or don't understand things, > while i'm trying to show the potentional bottlenecks of Announcements > framework itself... no continue I like to see arguments. Before consensus arise I like discussions because even lukas can be wrong ;D _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
In reply to this post by Stéphane Ducasse
> Now I would also like to know the cost of always broadcasting. I do
> not > remember correctly but in vassili'blog there were some points to avoid > that. > Because in the past, in Smalltalk the dependency where broadcasting to > all the > dependents and this was inadequate and after they introduce > on:when:..... > to get only the right listener updated. Yes, broadcasting was the reason why OBPackageBrowser was slow before we refactored it. Mondrian and OBPackageBrowser are happy with the current Announcement infrastructure. Cheers, Alexandre > > On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote: > >>> In current core image, Announcements is quite small (just around 10 >>> methods totally) and i doubt it provides enough >>> flexibility which would not require adding & reinventing additional >>> useful stuff on top of it. >> >> I have used these announcements in many large projects and I never >> needed to add anything. In fact, I would even vote to remove >> AnnouncementSet as I never used it or saw it used anywhere. >> Initially, >> I found it cool because the same trick is applied in the Exception >> hierarchy. Major projects like OmniBrowser (and to some extent also >> Seaside) use an even smaller subset of the functionality provided in >> the core package. >> >> The only thing that is maybe missing are weak announcements. I guess >> that could be useful, if Pharo provided a solid implementation of >> weak >> objects. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
>> Now I would also like to know the cost of always broadcasting. I do
>> not >> remember correctly but in vassili'blog there were some points to >> avoid >> that. > > Yes, broadcasting was the reason why OBPackageBrowser was slow > before we refactored it. Actually, the sloppiness came from the handlers associated to events. They generated way too many refreshes. Broadcasting events did not appear to be that slow. Users of an event mechanism have the tendencies to broadcast events more than it should be. Alexandre > > >> >> On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote: >> >>>> In current core image, Announcements is quite small (just around 10 >>>> methods totally) and i doubt it provides enough >>>> flexibility which would not require adding & reinventing additional >>>> useful stuff on top of it. >>> >>> I have used these announcements in many large projects and I never >>> needed to add anything. In fact, I would even vote to remove >>> AnnouncementSet as I never used it or saw it used anywhere. >>> Initially, >>> I found it cool because the same trick is applied in the Exception >>> hierarchy. Major projects like OmniBrowser (and to some extent also >>> Seaside) use an even smaller subset of the functionality provided in >>> the core package. >>> >>> The only thing that is maybe missing are weak announcements. I guess >>> that could be useful, if Pharo provided a solid implementation of >>> weak >>> objects. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
In reply to this post by Stéphane Ducasse
2009/11/2 Stéphane Ducasse <[hidden email]>:
>>> >> Oh yeah, i seen that code, and Dependents class var in Object class, >> which is a dictionary of dictionaries... >> This model, as well as morphic extensions, takes roots from Self's >> morphic, where you can easily extend >> any object state by adding new slots to it. In smalltalk we don't have >> dynamic named slots, and thus we >> having such ugly crutches :) > > > No it was before that. > It was because any object could have a dependent (even if model was > favored) > so for object the registration was stored in a large table. > >>> I hope we don't replicate this scheme, I had understood Announcements >>> did not thanks to explicit subscription. >>> Anyway, a bit of archeology is always helpfull when cleaning >>> Smalltalk... >>> >> >> It is strange, i have a feeling that people think i am being >> short-sighted or don't understand things, >> while i'm trying to show the potentional bottlenecks of Announcements >> framework itself... > > no continue I like to see arguments. > Before consensus arise I like discussions because even lukas can be > wrong ;D > I implemented a new announcer, which covers all functionality of the original one (all tests is green) but in addition enables you to subscribe directly via #subscribe: and receive #handle: message in case of announcements. Of course, the decision whether to handle or ignore announcement is up to subscriber. Next thing, which i tried to do is to add weak subscriptions. The syntax, i suggest is simple. As usual, for strong subscription you writing: announcer on: Announce do: [:ann | ... ]. (or any other message pattern) and for weak ones you writing: announcer weak on: Announce do: [:ann | ... ]. so, difference is in #weak keyword standing between announcer and subscription message. I think this is short and elegant, and doesn't forcing developer to learn or use different messages to subscribe weakly. The most powerful thing with weak subscriptions is, that we don't care about unsubscribing - the framework will automatically wipe the subscription entry, once subscriber becomes garbage. But there is a problem with an implementation of block based subscriptions (such as #on:do:). since, in block-based subscriptions, the real subscriber is a block receiver (a 'self' in block's home context) but not a block itself. So, we need to reference the block subscription strongly only if receiver of block is reachable by other means (not via subscription itself). The only way how we could do that withotut much hassle is to use ephemerons, but unfortunately, Squeak VM doesn't supports ephemerons, so support of weak block-based subscriptions is not possible without ugly hacks , like getting inside a block closure and patch its home context state (to get rid of receiver reference).. which is quite awful and error prone.. :( > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
On Monday, November 2, 2009, Igor Stasenko <[hidden email]> wrote:
> 2009/11/2 Stéphane Ducasse <[hidden email]>: >>>> >>> Oh yeah, i seen that code, and Dependents class var in Object class, >>> which is a dictionary of dictionaries... >>> This model, as well as morphic extensions, takes roots from Self's >>> morphic, where you can easily extend >>> any object state by adding new slots to it. In smalltalk we don't have >>> dynamic named slots, and thus we >>> having such ugly crutches :) >> >> >> No it was before that. >> It was because any object could have a dependent (even if model was >> favored) >> so for object the registration was stored in a large table. >> >>>> I hope we don't replicate this scheme, I had understood Announcements >>>> did not thanks to explicit subscription. >>>> Anyway, a bit of archeology is always helpfull when cleaning >>>> Smalltalk... >>>> >>> >>> It is strange, i have a feeling that people think i am being >>> short-sighted or don't understand things, >>> while i'm trying to show the potentional bottlenecks of Announcements >>> framework itself... >> >> no continue I like to see arguments. >> Before consensus arise I like discussions because even lukas can be >> wrong ;D >> > > I implemented a new announcer, which covers all functionality of the > original one > (all tests is green) but in addition enables you to subscribe directly via > #subscribe: > and receive #handle: message in case of announcements. > Of course, the decision whether to handle or ignore announcement is up > to subscriber. Can you give an example? I don't get it. > Next thing, which i tried to do is to add weak subscriptions. That's cool, however I would never use (or even provide) functionality depending on broken features. One can easily kill images with weak references on arbitrary objects like subscribers. > The syntax, i suggest is simple. As usual, for strong subscription you writing: > > announcer on: Announce do: [:ann | ... ]. > (or any other message pattern) > > and for weak ones you writing: > > announcer weak on: Announce do: [:ann | ... ]. > > so, difference is in #weak keyword standing between announcer and > subscription message. > I think this is short and elegant, and doesn't forcing developer to > learn or use different messages to subscribe > weakly. > > The most powerful thing with weak subscriptions is, that we don't care > about unsubscribing - the framework > will automatically wipe the subscription entry, once subscriber becomes garbage. > > But there is a problem with an implementation of block based > subscriptions (such as #on:do:). > since, in block-based subscriptions, the real subscriber is a block > receiver (a 'self' in block's home context) but not a block itself. > > So, we need to reference the block subscription strongly only if > receiver of block is reachable by other means (not via subscription > itself). > The only way how we could do that withotut much hassle is to use ephemerons, but > unfortunately, Squeak VM doesn't supports ephemerons, so support of > weak block-based subscriptions is not possible without ugly hacks , > like getting inside a block closure and patch its home context state > (to get rid of receiver reference).. which is quite awful and error > prone.. :( > > >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
2009/11/2 Lukas Renggli <[hidden email]>:
> On Monday, November 2, 2009, Igor Stasenko <[hidden email]> wrote: >> 2009/11/2 Stéphane Ducasse <[hidden email]>: >>>>> >>>> Oh yeah, i seen that code, and Dependents class var in Object class, >>>> which is a dictionary of dictionaries... >>>> This model, as well as morphic extensions, takes roots from Self's >>>> morphic, where you can easily extend >>>> any object state by adding new slots to it. In smalltalk we don't have >>>> dynamic named slots, and thus we >>>> having such ugly crutches :) >>> >>> >>> No it was before that. >>> It was because any object could have a dependent (even if model was >>> favored) >>> so for object the registration was stored in a large table. >>> >>>>> I hope we don't replicate this scheme, I had understood Announcements >>>>> did not thanks to explicit subscription. >>>>> Anyway, a bit of archeology is always helpfull when cleaning >>>>> Smalltalk... >>>>> >>>> >>>> It is strange, i have a feeling that people think i am being >>>> short-sighted or don't understand things, >>>> while i'm trying to show the potentional bottlenecks of Announcements >>>> framework itself... >>> >>> no continue I like to see arguments. >>> Before consensus arise I like discussions because even lukas can be >>> wrong ;D >>> >> >> I implemented a new announcer, which covers all functionality of the >> original one >> (all tests is green) but in addition enables you to subscribe directly via >> #subscribe: >> and receive #handle: message in case of announcements. >> Of course, the decision whether to handle or ignore announcement is up >> to subscriber. > > Can you give an example? I don't get it. you can subscribe using: announcer subscribe: object. and unsubscribe using: announcer unsubscribe: object. the argument 'object' should be responsible for implementing #handle: message which will receive all announcements from announcer, unfiltered. The rest of Announcer protocol (used by Announcements framework) built on top of it, as a superset. > >> Next thing, which i tried to do is to add weak subscriptions. > > That's cool, however I would never use (or even provide) functionality > depending on broken features. Please, can you elaborate, what you consider 'broken features' and why? I am also not a fan of using flawed stuff. That's why i talking about limitations of weak block subscriptions. While weak message subscriptions is easy to provide, using WeakMessageSend. > One can easily kill images with weak > references on arbitrary objects like subscribers. > true, as well as zillion other ways how you can shoot yourself in own foot. Nobody forcing one to use weak subscriptions, right? And if he does, its his own responsibility to make sure it working ok, not mine. >> The syntax, i suggest is simple. As usual, for strong subscription you writing: >> >> announcer on: Announce do: [:ann | ... ]. >> (or any other message pattern) >> >> and for weak ones you writing: >> >> announcer weak on: Announce do: [:ann | ... ]. >> >> so, difference is in #weak keyword standing between announcer and >> subscription message. >> I think this is short and elegant, and doesn't forcing developer to >> learn or use different messages to subscribe >> weakly. >> >> The most powerful thing with weak subscriptions is, that we don't care >> about unsubscribing - the framework >> will automatically wipe the subscription entry, once subscriber becomes garbage. >> >> But there is a problem with an implementation of block based >> subscriptions (such as #on:do:). >> since, in block-based subscriptions, the real subscriber is a block >> receiver (a 'self' in block's home context) but not a block itself. >> >> So, we need to reference the block subscription strongly only if >> receiver of block is reachable by other means (not via subscription >> itself). >> The only way how we could do that withotut much hassle is to use ephemerons, but >> unfortunately, Squeak VM doesn't supports ephemerons, so support of >> weak block-based subscriptions is not possible without ugly hacks , >> like getting inside a block closure and patch its home context state >> (to get rid of receiver reference).. which is quite awful and error >> prone.. :( >> >> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
>>> I implemented a new announcer, which covers all functionality of the
>>> original one >>> (all tests is green) but in addition enables you to subscribe directly via >>> #subscribe: >>> and receive #handle: message in case of announcements. >>> Of course, the decision whether to handle or ignore announcement is up >>> to subscriber. >> >> Can you give an example? I don't get it. > > you can subscribe using: > > announcer subscribe: object. > > and unsubscribe using: > > announcer unsubscribe: object. Ok, now I get it. I wonder why this would be useful? Also it looks to me like very bad programming style, as the specification of what to handle and the handler itself are merged. You can do that also with the original API, but it is less encouraging because you have to hand in twice the same object into #on:do:. Also, have a look at the Exception API. Announcements solve a similar problem and provide a similar API. It would be a pity to break that similarity. I've never seen a single project that extended the exception API, there the simple message #on:do: is enough for everybody. > Please, can you elaborate, what you consider 'broken features' and why? > I am also not a fan of using flawed stuff. Weak objects are flawed in Pharo and Squeak. If you have an unbounded number of weak references it can quickly happen that the system spends 95% or more of the CPU cleaning up the weak references. For Seaside 2.8 we spent quite some time in getting rid of all weak references, afterwards we had a cleaner, easier to understand and much faster solution. > That's why i talking about limitations of weak block subscriptions. > While weak message subscriptions is easy to provide, using > WeakMessageSend. I guess you could copy the BlockClosure, no? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
2009/11/2 Lukas Renggli <[hidden email]>:
>>>> I implemented a new announcer, which covers all functionality of the >>>> original one >>>> (all tests is green) but in addition enables you to subscribe directly via >>>> #subscribe: >>>> and receive #handle: message in case of announcements. >>>> Of course, the decision whether to handle or ignore announcement is up >>>> to subscriber. >>> >>> Can you give an example? I don't get it. >> >> you can subscribe using: >> >> announcer subscribe: object. >> >> and unsubscribe using: >> >> announcer unsubscribe: object. > > Ok, now I get it. > > I wonder why this would be useful? > > Also it looks to me like very bad programming style, as the > specification of what to handle and the handler itself are merged. there is no specification what to handle, because in my implementation the Announcer doesn't having any knowledge about nature of subscriptions. Its only task is to broadcast the announcement to all subscribers without any extraneous logic - consider an observer pattern in its purest form. Then there are a special kind of subscription, which handling announcements in style which were originally made for Announcer. And finally, i could turn your own argument back to you: why its Announcement deciding whether subscriber interested in it or not, by implementing checks in #handles: method at class side? Isn't this a mixing of 'what to handle' and 'handler' roles? > You > can do that also with the original API, but it is less encouraging > because you have to hand in twice the same object into #on:do:. > passing twice? I think you meant passing once, i.e.: announcer on: Announcement do: self which can be a roughly equivalent to announcer subcscribe: self. except that this case you will need to implement own #valueWithArguments: and #receiver methods while in my variant - #handle: , and except that current framework will do unnecessary #isKindOf: checks before delivering announcement to such handler. > Also, have a look at the Exception API. Announcements solve a similar > problem and provide a similar API. It would be a pity to break that > similarity. I've never seen a single project that extended the > exception API, there the simple message #on:do: is enough for > everybody. > but there is #on:do:! So, if one think its enough for him - no problem just use it, and forget about #subscribe:. How it breaks the similarity (which i find good myself btw), when it providing same functionality as current one? By enabling more generic form of subscription? Oh cmon... >> Please, can you elaborate, what you consider 'broken features' and why? >> I am also not a fan of using flawed stuff. > > Weak objects are flawed in Pharo and Squeak. If you have an unbounded > number of weak references it can quickly happen that the system spends > 95% or more of the CPU cleaning up the weak references. For Seaside > 2.8 we spent quite some time in getting rid of all weak references, > afterwards we had a cleaner, easier to understand and much faster > solution. > i don't expect too many subscribers to a single announcer (do you?), and the number of weak ones could be even less than that. I think that if announcer keeps more than 10-20 subscribers, it will already a signal that you start abusing framework. :) So i don't think that cleaning it up will be an issue or bottleneck in this case. And of course i am aware of potential pitfalls of weak finalization in squeak. But hey: we don't care about managing memory in smalltalk, why we should abandon idea to have an automatically managed weak subscriptions? Since you usually never send #dispose/#free for each corresponding #new, it is logical to have an option to never send #unsubscribe: for each corresponding #subscribe: , isnt? It imples some discipline? Yeah. As well as #new does, because if you attempt to allocate memory in a run-away fashion, you will end-up with memory overflow. >> That's why i talking about limitations of weak block subscriptions. >> While weak message subscriptions is easy to provide, using >> WeakMessageSend. > > I guess you could copy the BlockClosure, no? > This will give nothing. The problem that BlockClosure holding all references strongly, as well as any context object. And even worse - the real subscriber (our object of interest) is not held directly by a closure, but by its home context object. And there is no guarantees that given context's state keeps reference to subscriber only in 'receiver' slot. It could be kept in temps or temps could reference the receiver etc etc. And you can't hold a BlockClosure weakly, because it will vanish once you exit from #on:do: method. So, the only solution is to keep it strongly as long as receiver are referenced strongly by something outside the BlockClosure references subgraph. This is what ephemeron does, but its impossible to implement using weak refs. > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
In reply to this post by Lukas Renggli
At Mon, 2 Nov 2009 19:18:09 +0100,
Lukas Renggli wrote: > > > Please, can you elaborate, what you consider 'broken features' and why? > > I am also not a fan of using flawed stuff. > > Weak objects are flawed in Pharo and Squeak. If you have an unbounded > number of weak references it can quickly happen that the system spends > 95% or more of the CPU cleaning up the weak references. For Seaside > 2.8 we spent quite some time in getting rid of all weak references, > afterwards we had a cleaner, easier to understand and much faster > solution. Just to be clear. Is it because the need to process the dictionary that registers the objects needs to be finalized, right? For this case, these subscriptions objects don't have to be finalized, I think. The subscriber holds onto a WeakArray of size one, and the element just becomes nil. And when announcing something, you can just skip (and remove) subscription objects who have nil subscribers. Or, is there actually a problem just having weak arrays? -- Yoshiki _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
In reply to this post by Igor Stasenko
Igor Stasenko wrote:
> 2009/11/1 Tudor Girba <[hidden email]>: > >> 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. > just reading this interesting thread... > 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. > I guess you speak about my remark in the "ClassOrganizer oddities" thread. Here is what I said: ------------------------------------- > You defined a set of announcement classes, each one is for a particular > kind of event. > So, no need for #changeKind and #parameters dictionary instance variable > (please no!). -------- end---------- just to be clear, the "please no!" was for the dictionary because it can make the code difficult to maintain (Morph properties ...). why not the #changeKind variable even I prefer expressing them by subclasses. > 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. > yes and having a well defined announce hierarchy is not so easy. Cheers Alain _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
In reply to this post by Yoshiki Ohshima-2
2009/11/2 Yoshiki Ohshima <[hidden email]>:
> At Mon, 2 Nov 2009 19:18:09 +0100, > Lukas Renggli wrote: >> >> > Please, can you elaborate, what you consider 'broken features' and why? >> > I am also not a fan of using flawed stuff. >> >> Weak objects are flawed in Pharo and Squeak. If you have an unbounded >> number of weak references it can quickly happen that the system spends >> 95% or more of the CPU cleaning up the weak references. For Seaside >> 2.8 we spent quite some time in getting rid of all weak references, >> afterwards we had a cleaner, easier to understand and much faster >> solution. > > Just to be clear. Is it because the need to process the dictionary > that registers the objects needs to be finalized, right? For this > case, these subscriptions objects don't have to be finalized, I > think. The subscriber holds onto a WeakArray of size one, and the > element just becomes nil. And when announcing something, you can just > skip (and remove) subscription objects who have nil subscribers. > backstabbed with impossibility to make block-based subscriptions weak. :) Since we expect that eventually there will be a new announcement, we could wipe weak entries during this cycle. Keeping a garbage entries until new announcement will come don't seem to be a big problem. > Or, is there actually a problem just having weak arrays? > No, i think the main issue is an overhead of squeak's finalization logic. > -- Yoshiki > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
In reply to this post by Alain Plantec-4
2009/11/2 Alain Plantec <[hidden email]>:
> Igor Stasenko wrote: >> 2009/11/1 Tudor Girba <[hidden email]>: >> >>> 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. >> > Hi Igor and all, > just reading this interesting thread... >> 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. >> > I guess you speak about my remark in the "ClassOrganizer oddities" thread. > Here is what I said: > ------------------------------------- >> You defined a set of announcement classes, each one is for a particular >> kind of event. >> So, no need for #changeKind and #parameters dictionary instance variable >> (please no!). > -------- end---------- > > just to be clear, the "please no!" was for the dictionary because > it can make the code difficult to maintain (Morph properties ...). > why not the #changeKind variable even I prefer expressing them by > subclasses. (see the end of this post) >> 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. >> > yes and having a well defined announce hierarchy is not so easy. > that's why for sketching purposes, i'm using dictionary of arguments, not keyword messages and not building a class hierarchy of different change kinds. At this stage it is unclear what follows what, what is the final set of arguments for each change kind, and so i prefer to generate events using less 'early-bound' way. > Cheers > Alain > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
I just uploaded the modified announcer code + new tests.
Please check the http://www.squeaksource.com/PharoInbox/Announcements-Slice-Igor_Stasenko.1.mcz and send a feedback -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About AXAnnouncements (was: some Announcements related questions)
|
|
2009/11/3 Igor Stasenko <[hidden email]>:
> I just uploaded the modified announcer code + new tests. > Please check the > > http://www.squeaksource.com/PharoInbox/Announcements-Slice-Igor_Stasenko.1.mcz > > and send a feedback > oh.. for those who interested , but too lazy (or busy) to check it out.. - added a generic #subscribe: form of subscription. - added weak subscriptions support (except block subscriptions). Also, unsubscribing is allowed during handling an announcements, as well as nested announcements (these two features should work ok, but i didn't covered them with tests). > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |