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