what is a parallel array? > 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:pharo- >> [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
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
