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. > 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
