I got it after sending it :) On Oct 31, 2009, at 5:31 PM, Stéphane Ducasse wrote:
> 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
