Take a look in this thread: http://thread.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/15001/focus=15... ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Tudor Girba [tudor.girba@gmail.com] Sent: Tuesday, January 18, 2011 2:52 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Unsubscribing for Announcements Who defended what status quo? The WeakAnnouncement are already on the agenda for 1.3. Cheers, Doru On 18 Jan 2011, at 20:40, Schwab,Wilhelm K wrote:
Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Tuesday, January 18, 2011 2:22 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Unsubscribing for Announcements
Yes but having good weakstructure will not arrive by accident.
On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote:
Two comments:
(1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional.
If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements
I really like Announcements! It's so much easier to update complex GUIs when you can pass state :)
I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe).
I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete.
SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete.
But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted?
Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow."