---- On Mon, 06 Dec 2010 15:42:01 -0800 Igor Stasenko wrote ----
>On 7 December 2010 00:18, jaayer wrote:
>>
>>
>>
>>
>> ---- 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 protocol. It is, however, part of the ANSI
>> 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?
>
>i think that most sane developers trying to avoid using inconsistent
>methods with dictionaries , which inherited from Collection protocol.
>So, instead of #do:, they using #valuesDo: , dict values select:
>instead of dict select: and so on.
>Because otherwise, what is the point of introducting #valuesDo:, which
>completely duplicating #do: behavior? I see nothing, except an attempt
>to introduce an explicit and more appropriate protocol for Dictionary.
>And then ban Collection methods, with questionable behavior (depending
>on who is questioning ;) ).
I am not sure if you realize this or not, but "dict values select:" and "dict
select:" do two different things. The former selects the values of "dict" into
a new collection, as one would expect, while the latter actually creates a new
dictionary by filtering the associations from "dict" based on the values of
those associations. Another datum, assuming you were unaware of the difference,
for the unintuitiveness and relative uselessness of the enumeration protocol of
Dictionary. When have you ever really needed something like what
Dictionary>>select: or Dictionary>>collect: provides? How often are you
interested only in the values of a dictionary and not their corresponding keys?
It may be ANSI, but it was poorly thought out, and it stinks.
A Dictionary is an unordered collection of associations. That means #add:,
#do:, #select:, #size, #includes: and other messages belonging to the basic
protocol Dictionary inherits from Collection should operate on associations and
not association values. At least, I suspect that's how it would be done if it
could be done anew, without any concern for existing standards or backwards
compatibility.
>>
>>>--
>>>Best regards,
>>>Igor Stasenko AKA sig.
>>>
>>>
>>
>>
>>
>
>
>
>--
>Best regards,
>Igor Stasenko AKA sig.
>
>
