Stef, Fair enough. What do you think of the shared lookup table I posted?
Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stéphane Ducasse Sent: Friday, January 08, 2010 5:06 AM To: [email protected] Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus Build something and propose it. Continue to discuss and get a group of people working on the solution. Good solution should emerge but code is important. Stef > Henry, > > Then we need to fix the weak collections. Dolphin (of the mid-90's) already > had thread-safe weak collections and a high-priority process to detect and > clean up "damage" to them; it's time to catch up. > > The more I think about it, your idea is sounding a lot like the dependency > days of MVC - remember #release? I'm trying to forget. > > I am not trying to be confrontational, but we can and should do better than > this. > > Bill > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Henrik Sperre Johansen > Sent: Thursday, January 07, 2010 8:27 PM > To: [email protected] > Subject: Re: [Pharo-project] Notifications of windows > opening/closing/focus > > On 08.01.2010 02:07, Schwab,Wilhelm K wrote: >> Henry, >> >> No argument, your solution is simpler. However, we do not have >> announcements like this now, and it appears that the poor state of weak >> collections in Squeak/Pharo is standing in the way of a clean >> implementation. My vote is to tackle the weaklings, at least until they >> work well enough to support what we should have in this case. Otherwise, we >> kick the weak can down the road as has been done all along rather than >> fixing it, AND we end up with a sub-standard announcments-based framework. >> >> Let's do it right. We will then have an evolving/improving weak collection >> and something in the image that puts some stress on same. If I'm missing >> something, please enlighten me. >> >> Bill >> > Weak collections does not stand in the way of making the use case of > unregistering dynamic registrations manually easier. > They stand in the way of the use case of unregistrating registeration > automatically. > > Here's what you're missing: > No matter how you implement the automatic unregistering, it will be > nondetermenistic, for the exact same reasons finalization is nondeterministic. > Thus, if you require deterministic unregistration, you have to do it > manually, and the use case of making that easier to do have value in its own > right. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
