2009/11/2 Lukas Renggli <[email protected]>: > 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.
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 >>> [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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
