Hi Eliot,

...

...

...

This is experimental, not guaranteed bugfree. Indeed, you cannot #add: to nor #remove: from an Array... and elements won't be unique. My trunk image did not freeze because I analyzed senders of #selectors in it. But sure, this might break foreign code... So yes, it deserves discussion.

What do others think ?

I agree with Eliot. Keep the changes minimal - so just replace "keys" with "keys asSet" where necessary.

- Bert

Me too. #selectors should return a Set.

Colin

Though I found no such usage in MC1.0 :) But I didn't inquire MC2.0, DeltaStreams, Etoys nor any other reflexion crunching packages...

BTW, it would be great to have universal code analysis tools spreading over a public code database, not just my image. It dream of such database served through web pages...

Nicolas

Last thing, before retracting this change, I give hereafter a little rationale of my choice: There were 92 senders of selectors in trunk, I classified into three categories 1) Some senders performing add: or remove: If I recall, only 3 of them were I placed some #asSet protection. 2) Some senders expecting unique keys : but hey, selectors have unique elements because methodDictionary keys are unique... Only those aggregating with other selectors care, but most of them explicitely addAll: to an empty IdentitySet... 3) Every others did use an Array compatible message like do: includes: select: collect: asSortedCollection etc... Then I analyzed the cost of selectors: 1) Array will perform better than Set for all these selectors, but includes:. 2) Most direct senders of selector includes: SHOULD better be written includesSelector: Rationale: a single message send that will test includesKey: rather than two creating unecessarily an intermediate Set 3) 95% of senders would now uselessly perform an additional #asSet operation So my analyze was that I would personnaly buy this little optimization with the drawback of having to rewrite 5% of senders at most. But of course, I don't offer to rewritte your code, so I understand your opinion may differ :) And of course I agree that optimized code that breaks has no value. That's just a matter of tradeoffs. Nicolas