Take a look in this thread: http://thread.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/15001/focus=15167
________________________________________ From: [email protected] [[email protected]] On Behalf Of Tudor Girba [[email protected]] Sent: Tuesday, January 18, 2011 2:52 PM To: [email protected] 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: [email protected] > [[email protected]] On Behalf Of Stéphane Ducasse > [[email protected]] > Sent: Tuesday, January 18, 2011 2:22 PM > To: [email protected] > 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: [email protected] >> [[email protected]] On Behalf Of Sean P. DeNigris >> [[email protected]] >> Sent: Monday, January 17, 2011 1:18 AM >> To: [email protected] >> 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."
