2009/10/31 Schwab,Wilhelm K <[email protected]>: > 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 > >
Squeak.MethodDictionary is an example of this pattern too > > -----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 > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
