Em 07/01/2011 16:43, pharo@googlecode.com escreveu:
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.
The ambiguity is of course a thing we have to qualify. The Collection hierarchy of Smalltalk uses Integers for indices for accessing elements. This is something you need to learn to be able to use these classes.
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
Well the word 'copy' seems to indicate the it doesn't change self, if it did, we should open another issue and search for a fix. The other part of the enthymeme of yours must be pointed out to practicality and the sensible thing to do. The return would most of the time be the most appropriate collection given the intent of the extraction done by the method. Pathological cases should be issued and discussed for a fix.
- or an element are arguments elements or indices
There is a limit on the 'non knowledge' you can [not] have in order to use the methods of a determined class. In Pharo you have as a last recourse the browsing of the method implementation itself.
should be reflected in the naming of the method, if one wants to avoid having to read the implementation/comments.
There should be a balance between the three. Otherwise you'll end up with too verbose API ("interface") for doing the daily chores, and people will frown and stop using the language. Even with OCompletion and friends, the most common operations should strive to have short method names and be relatively mnemonic for people who get trained in the environment/technology/language.
Currently, every method having copy in its name has to be examined closely, to be able to decide what behavior should be expected.
Once we get evidence on this we could proceed. Do you have any case to show us?
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.
No. We have a history and production code to live with as well. In extremis your suggestion is better accomplished with a proposal for a new, parallel, hierarchy of classes with a 'better' interface, which put in the ecosystem should show if its benefits make developers to change to it instead of the present one. my 0.019999... -- Cesar Rabak