Hello all, FWIW, Dolphin "lookup tables" use parallel arrays for keys and values. OA's claim (I do not dispute it, I'm simply reporting what they said) is that the result is faster than a dictionary based on associations.
Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nicolas Cellier Sent: Saturday, October 31, 2009 9:23 AM To: [email protected] Subject: Re: [Pharo-project] dictionary value is an array? 2009/10/31 Igor Stasenko <[email protected]>: > 2009/10/31 Nicolas Cellier <[email protected]>: >> 2009/10/31 Stéphane Ducasse <[email protected]>: >>> >>> Hi nicolas >>> >>> If I remember you proposed fixes to have dictionary values -> array? >>> Is it correct? >>> >>> I was wondering why? >>> Because a set makes more sense to me since >>> - the order of the elements in values is not useful (because >>> they come from a dict) >>> - the occurrences not really either >>> - we cannot add to the results so we should create another >>> collection >>> >>> May be I'm totally wrong with the changes but I think that values >>> should be set while keys an array. >>> I would be interested in discussion on that. >>> >>> Stef >>> >>> >> >> Dictionary values is already an Array... >> I proposed to change keys accordingly. >> >> Historically, they were a Bag and a Set because they were unordered. >> >> But very few or no sender expect a behavior specific to a Bag or a Set. >> Most just do: select: collect: asArray asSortedCollection etc... >> That's where an Array outperforms a Set or a Bag. >> >> So we are paying the price of a Set or a Bag almost for nothing... >> And that is why you can see a #fasterKeys. >> >> The drawback is that a few senders will add: to or remove: from keys. >> My estimation is around 5%. >> Inside the image, no problem, it is easy to fix, just write >> (someDictionary keys asSet). >> But that put a load on package maintainers. >> > > +1 Nicolas. Personally, i think that modifying a collection which not > constructed by your own code > is bad programming style, because you never know where this collection > is came from and you can't be sure that there is no other users of it, > which in own turn may modify it at any moment, while often you > assuming that only you own the collection and don't expecting any > modifications to it except in own code. > So, IMO this approach is error prone, and you should never use > #remove: or #add: with collections which constructed by separate > package/layer, and instead, use #asSet, #asOrderedCollection and, of > course #copy, before starting manipulating its elements. > I agree. removing from another one's collection is not that well behaved ! It's putting expectations higher than necessary. I see this as a sort of optimization breaking encapsulation... I want to come with a better optimization. Unfortunately, historical uses will be found here and there, #keys being a well-known case. We have to put pressure on maintainers... Who ever takes this path shall be ready to sell the idea, and prove that gains > costs. A team modifying kernel in uncompatible manner (and we have to, or just stick to Squeak 3.7) shall provide support for a smooth transiiton. Sometimes I feel it would be convenient to inquire a code base larger than just an image, so that we can emit proposals and sell the idea rather than just waiting for complaints passively.... Nicolas > >> Nicolas >> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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
