Comment #19 on issue 3436 by step...@stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 Nicolas wrote:
All the other messages could have had the copy prepended if it was a question of homogeneitty with existing API. The fact is that they were added later than copy and copyFrom:to: Of course, we can as well remove the copy prefix, but do we really care ? Is it really what makes the message ambiguous ?
It is one of the ambigueties.
If I wouldn't know about the message, my question would not be about whether or not the message triggers a copy. It would be whether the argument are elements or indices.
- does it return a copy or change self - does it return a collection or an element - are arguments elements or indices should be reflected in the naming of the method, if one wants to avoid having to read the implementation/comments. Currently, every method having copy in its name has to be examined closely, to be able to decide what behavior should be expected. Overriding semantics is less than helpful, as that leads to more confusion. As long as there is no clear naming convention, it is better to add new method names than to overlay new behavior on existing ones.