On 23.02.2010 19:01, Stéphane Ducasse wrote: >> I've been meaning to make system-change notifications for Pharo so the >> recording-part could work there too, but I never seem to get around to it :( >> Part of the problem is of course my own personal "The Best Way"(tm), >> which f.ex. would include Announcements. >> Since I'd like the ability to have Weak subscriptions, I'd first have to >> deoptimize the Announcement-package Levente made a bit to make it >> "prettier", > can you explain a bit more the technical aspect? Well, Levente's implementation, each kind of arg has it's own Subscription class, for performance reasons. What I was hoping to do was consolidate these so there's only two classes, one for Strong, and one for weak subscriptions. Using cull: this is possible, with a small performance penalty at subscriber evaluation time (IIRC, 4 times less overhead compared to valueWithPossibleArgs:, but double the overhead of direct value: evaluation which you achieve with the one-class-per-arg-type approach ), but with faster subscription creation. Thus, you get a simpler implementation at the cost of some performance.
Lacking Weak subscriptions is, as Bill put it in an earlier mail: "a lot like the dependency days of MVC - remember #release? I'm trying to forget" - If you don't outlive your announcer, you have to unsubscribe manually to be GC'd. >> make it a strict superset of what if found in Core already, >> fix WeakRegistry so each resource registered for an object actually gets >> finalized, which again means... etc... Oh, and hope it'd end up good >> enough that it'd warrant inclusion:) > I would love to see a bit more enhancement on Announcement. I described the issue with WeakRegistry>>toFinalize:send:to:with: in a previous mail, it's only related in the term that Levente's implementation uses it. (I encountered it while writing some tests for weak subscriptions) Reading Squeak-Dev, it seems he's picked it up, and there's a version in the Inbox, I'll be reviewing that :D As for the Announcement implementation, AXAnnouncements follow what was described in the post of Vassily more closely, which both make use of them more portable, as well as provide some other benefits, the ones which seems of most value to me is the simple implementation of weak subscriptions, plus support for registering actions taking more than the announcement itself as a parameter for handlers. http://n4.nabble.com/Notifications-of-windows-opening-closing-focus-td1296554i20.html#a1296592 (where the above quote is taken from) contains a relevant discussion as to why I find these features useful. Changing Lukas' implementation as provided in Core to do the same, (I think) you'd loose much of its simple elegance The one thing I'm ambivalent about regarding VW/AX implementation vs. Lukas', is whether when:do: should be setting the block as subscriber (VW) instead of the instance sending when:do: (Lukas). When using this method together with strong subscriptions in VW, I almost always ended up using when:do:for: so I could register the instance as subscriber instead. Cheers, Henry _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
