2014-11-28 16:39 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:On Fri, Nov 28, 2014 at 4:26 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:I think that is the most logical thing to do, it is what I would expect.
> On 28 Nov 2014, at 15:35, Marcus Denker <marcus.denker@inria.fr> wrote:
>
>
>> On 27 Nov 2014, at 08:21, Marcus Denker <marcus.denker@inria.fr> wrote:
>>
>>
>>> On 26 Nov 2014, at 19:19, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>>>
>>> Hi All,
>>>
>>> IdentitySet>>collect: answers a Set, not an IdentitySet. Anyone else agree this is a serious bug? Anyone else disagree?
>>>
>>> WTF??
>>>
>>> (IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e] a Set(1.0 2 3)
>>
>> Yes, I would say so. I think we fixed some others like that already (not 100% sure)
>>
>> I added an issue tracker entry
>>
>> 14535 IdentitySet>>collect: answers a Set, not an IdentitySet.
>> https://pharo.fogbugz.com/f/cases/14535
>>
>
> #collect: directly uses Set in Set>>#collect, I committed a fix (to the issue tracker, to be reviewed)
> to use ���self species��� instead (plus the example from above as a test in IdentitySetTest).
>
> Marcus
I know others have cases where that is not really what you want (some of Set's subclasses are pretty special), but it is still a good default, while #collect:as: can be used for all other cases (and subclasses can override #species again if they want).
Hmm... errors found by the test runner on that change.So we will need to check...MarcusIn pharo, the problem is the OCKeyedSet, but the same happens in squeak with a KeyedSet.Changing Set>>#collect: to use "self species new" the following code fails:
k:=KeyedSet new keyBlock:[:e | e name].
k addAll:{ Color red . Color blue . Color green}.
k collect:[:e | e ].
--> MessageNotUnderstood: Color>>key