[Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Jan 7 15:17:54 EST 2011


2011/1/7  <csrabak at bol.com.br>:
> Em 07/01/2011 15:10, Nicolas Cellier < nicolas.cellier.aka.nice at gmail.com > escreveu:
>
> You make excellent points Nicolas!
>
>
>> 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  ?
>
> I think we should, as the removal would have ripple effects in production code.
> Our reasoning should be some sort of ROI on it.
>
>> Is it really what makes the message ambiguous ?
>
> I would argue that the presence of 'copy' suffix makes them _less_ ambiguous as
> far as the methods in question effectively do a copy on the receiver.
>
>>  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.
>
> You mean that once you have removed the 'copy' prefix or as the method names stand right now (and I mean for the ones this issue number is about)?
>
>>  I could expect:
>>  #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'.
>>  to work like:
>>  #( 'foo' 'bar' 'baz') after: 'foo'.
>
> I would like to elaborate on your half million question « Is it really what makes the message ambiguous ? »
>
> If you attempt your example in plain Pharo image
>
> #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'.
>
> You get a MNU
>
> ByteString(Object)>>doesNotUnderstand: #-
> Array(SequenceableCollection)>>copyFrom:to:
> .
> .
> .
>
> So what would be your point:
>
> 1) copyFrom:to: is not 'polymorphic enough' for Pharo Smalltalk ideal of a dynamic language?
>
> 2) the message name is to be changed to copyFromIndex: start toIndex: end?
>
> 3) some other concoction I missed?
>
>
> HTH
>
> --
> Cesar Rabak
>
>

Here is what I mean:
I agree that #copyFrom: is ambiguous and could be renamed, with all
deprecation precautions.

But concerning #copyFrom:to: I think this name is a non issue for code
readability.
I decided to play advocatus diaboli just to push a bit absurdness of
this ubuesque thread.
In Smalltalk, you have to trust what you read, and to me (aString
copyFrom: 2 to: aString size - 3) is obviously a copy, and arguments
are obviously indices, what else could it be ?
So no, I don't suggest to drop the copy though it's not strictly
necessary, nor to append an Index to the name.
Who never browsed senders of such message in squeaksource code base
could have such a foolish idea.

For writing code, we can't just guess an API, so this is a non issue too.
I can't guess the name, it could be #copyFromStartIndex:toStopIndex:
or just #from:to:, no way the API will fit everyone's brain.
For writing code we have these alternatives:
- Open a Browser and browse the collection classes
- learn idioms from reading other code
- learn idioms from a tutorial or a help system
- type a keyword in a message finder, or some receiver arguments and
expected results.
All these actions will clearly disambiguate the semantic of
copyFrom:to: arguments.
We can tolerate some level of ambiguity when the send sites will disambiguate.

As for homogeneity, I don't propose anything but statu quo.
I understand (aString first: 3) as well as extending (aString first),
and I can reasonnably guess it will answer a copy too, why the hell
would this innocent message change aString state ? Does (aString
first) do ?
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.

Nicolas




More information about the Pharo-dev mailing list