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:

> 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 think that is the most logical thing to do, it is what I would expect.

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


In 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