>> >> 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.
Igor why? why remove: does not take the same argument than add: and does what it should? >> 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 hope not.
