John, I'm not sure whether we agree or disagree on individual points, but that's ok. I will invoke Sig in the case of 10^6 entries - something tells me one would end up with a customized implementation long before a weak collection became that large. However, I think automatic cleanup is important to keep a long-lived map from getting that large. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Tuesday, October 27, 2009 12:27 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections On 2009-10-26, at 10:37 PM, Igor Stasenko wrote:
and why the key should go away? I think that this is an implementation nuance, but not bug or missing feature. No-one would expect from dictionary keys to automatically mutate depending on the state of the associated values. If you want such behavior, why not implement own WeakLookupTable ?
Ok, well (a) I don't think any of the set or dictionary logic is particularly written with thread safety in mind. No doubt a Mutex is needed to protect the integrity of the data. Someone can decide which version of Pharo should a fix for 0006955 (b) Although as Igor mentioned the fact the key goes away is a implementation detail, this in fact is useful. The situation you run into is storing entities in a weak value dictionary where the values do disappear however if you store a million entries then you end up with a million keys, so who is responsible for the cleanup? -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project