2011/1/7 <csrabak@bol.com.br>:
I will take this as meaning "I agree that Object>>copyFrom: is ambiguous..."
If I misunderstood you, please feel free to correct.
OTHO, as it is not explicitly written, I would like to understand your stance on having this method name as a shorcut to copyFrom: start to: (self size).
I don't think it's a good idea for backward compatibility reasons. Changing the semantics of #copyFrom: is worse than just deprecating the message. Do we really need this message ? For porting a package from another dialect ?
I do agree 100% on this. Â However, there is a rub:
aComplicatedName copyFrom: pocnu to: kraja.
What can they be? Â As Smalltalk is dynamic even if you could see the
|pocnu kraja| . . . you'll probably would need to see the implementers of the code that attribute values to these (say) local variables.
Of course, one can always obfuscate its code, and the naming of these variable is well chosen with this respect.
Again I think this is a reasoning that only can be explained due being too comfy in our crib:
Put this stub of code in a book (especially if the dead tree variety) and claim that it is only a 'browsing of sender' away and you will understand WHY the whole thread is not that much "ubuesque" as it seemed at first...
We can perfectly write a book explaining these selectors. Just group the selectors (copy copyFrom:to: etc..), explain copy vs partial copy, and explain theses selectors are in the ANSI standard API. Then group the selectors (first, first: etc..), explain that they are extensions, and don't need a copy prefix, because anyway most messages will do a copy.
The semantics of copyFrom:to: are not the issue. The issue as is written in the issue tracker _and_ the subject line is the semantics of copyFrom:
Agree, but i was seeing this thread derivate a bit.
 So no,  I don't  need to  add a  copy prefix  to this message, and no i don't really care for a higher homogeneity.  If we change  a few missnamed selectors here  and there, that's OK, but  if  we change  a  large amount  of  Kernel  messages with  many senders, it's a  recipee for Pharo rejection, because  we would make developer's life a hell for no valid reason.
Or not! There is no reason why a newer "kernel" be created and if the usage of it be so compelling or productive or practical or ....<put your favorite marketing word> that it takes over the present state of affairs in the usage of Smalltalk, why not!?
Well, we have to balance pros and cons of changing, especially in the kernel.
-- Cesar Rabak