>
> 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
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
