On Monday, November 2, 2009, Igor Stasenko <[email protected]> wrote: > 2009/11/2 Stéphane Ducasse <[email protected]>: >>>> >>> 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
