On 7 December 2010 00:18, jaayer <[email protected]> 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 <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?
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 ;) ). > >>-- >>Best regards, >>Igor Stasenko AKA sig. >> >> > > > -- Best regards, Igor Stasenko AKA sig.
