---- On Mon, 06 Dec 2010 15:07:34 -0800 Igor Stasenko wrote ----
>On 6 December 2010 23:52, jaayer wrote:
>>
>>
>>
>>
>> ---- On Sun, 05 Dec 2010 12:44:46 -0800 jaayer wrote ----
>>
>>>Is anyone else bother[ed] by this inconsistency?
>>
>> Apparently not. Well, I uploaded two packages to the PharoInbox. One adds
>> #remove: and #remove:ifAbsent: to Dictionary and updates SmallDictionary's
>> implementations of those messages to return the same value - the association
>> removed - rather than their current behavior of #remove: returning self (no
>> explicit return value) and #remove:ifAbsent: returning the key of the
>> removed association. The second package adds #testRemove and
>> #testRemoveIfAbsent to DictionaryTest (through a trait).
>>
>>
>
>Hello, jaayer.
>
>The point about Dictionary inconsistency was raised multiple times before.
>I was among ones of those who did that couple of years ago.
>What can i say?
>While it is much better to have consistency,
>in fact it doesn't really changes much. I don't think that #remove: in
>a form you proposed will be any userful.
>I would really keep it simply #shouldNotImplement , because it is
>unclear what is a least surprising behavior of this method for
>Dictionary.
>One might argue, that its more userful to make it same as #removeKey:,
>other one could point that its should be symmetrical to #add: ,
#add: is not part of the ANSI <abstractDictionary> protocol. It is, however,
part of the ANSI <extensibleCollection> protocol:
add:
addAll:
remove:
remove:ifAbsent:
removeAll:
One could make the argument that if Dictionary elects to implement part of it,
it might as well implement the rest too.
>but hey, then #do: should be also symmetrical to #add: , isnt? And so
>it should iterate over associations , not just values. So, it is a can
>of worms, once you open it , you can never finish the endless
>discussions :)
>It is just works in a way how we like (defined). It is like an
>imaginary numbers in math where sqrt(-1) == i and basta :)
Right... I wasn't planning on going there, but are we basically stuck with
#do:, #select: #collect:, #includes: and other such messages operating on the
Dictionary's values rather than its associations, forever?
>--
>Best regards,
>Igor Stasenko AKA sig.
>
>