Comment #3 on issue 3436 by sebastianconcept: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 I don't get it. When you take any non squeak based smalltalk you'll see that #copyFrom: is consistent and intuitive. When you take Pharo you get that: 1. it's broken even for smalltalkers (imagine random citizens) 2. is manipulating (admitedly) dangerously (check implementor comment) 3. is doing something extremely primitive without using the prefix basic (or whatever that suggest that this is a thing to use unless you know what you're doing) 4. our community response is that reporting this is invalid? Can we please fix this instead of rationalize? Suggestion: a rename of the current Object>>copyFrom: will be enough. How to rename it? with something that suggest is going to manipulate the freaking instance variables) there is code depending on that? screw it. If they started with the wrong foot, they should pay the price of their upgrade (they are guilty of creating a dependence on something broken).

Comment #5 on issue 3436 by rydier: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 If we end up deprecating and reimplementing, at least make the "new" implementation in SequenceableCollection, where it can be found in STX and GnuST. I still don't think it's a good idea to add to the SequenceableCollection API though, because: - It's not ANSI (VW for instance does not have it) - There is already copyFrom:to: and allButFirst: filling the same role nearly as easy - It'll break code for no better reason than to increase readability (unless you actually look up its implementation, in which case it's quite clear what it does) - There's yet another point of difference if you want to have your code running on both Squeak and Pharo

Comment #7 on issue 3436 by rydier: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 The argument would be one off? allButFirst: n == copyFrom: n+1

Comment #9 on issue 3436 by step...@stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 Then the real question is: why do we have copyFrom:to:? To be in collection protocol style, that could be from:to:. It is not reliably derivable from the protocol name if you get a copy or mutate the original.

Comment #11 on issue 3436 by step...@stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 The problem is that it clearly does nothing at all to improve readability and usability, as long as there is no consistent and complete interface. Without a complete interface redesign, this simply is no improvement.

Comment #13 on issue 3436 by step...@stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 I have to disagree strongly. It is absolutely unclear why the 'copy' is part of the method name in copyFrom:to:. It therefore is a change in the wrong direction.

Comment #15 on issue 3436 by rydier: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 GnuST does the copyFrom: to: self size shortcut as well. VW does not define copyFrom: in Object. Implementors in the packages I had loaded: -ProbedCompiledMethod/Blocks do the same. -GlorpAttributeModel copies some, others only if nil in receiver, and the rest not at all.

2011/1/7 <pharo@googlecode.com>:

Comment #16 on issue 3436 by step...@stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436

5.7.8.7 does not adequately explain why copy should be part of the method name. To me it looks like accidental complexity, and I would like to avoid spreading it.

Because you have two ways to copy a string : - a copy of the full string - a partial copy from start index to stop index does this POV makes it clearer ? 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 ? Is it really what makes the message ambiguous ? 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. I could expect: #( 'foo' 'bar' 'baz') copyFrom: 'bar' to: 'baz'. to work like: #( 'foo' 'bar' 'baz') after: 'foo'. Nicolas 2011/1/7 <pharo@googlecode.com>:

Comment #17 on issue 3436 by step...@stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436

Nicolas wrote:

...

Because you have two ways to copy a string : - a copy of the full string - a partial copy from start index to stop index does this POV makes it clearer ?

This does not help, as we also have a.o. - allButFirst: - allButLast: - first: - last: -reverse: - sortBy:

and compare to: - after: - before: - appendTo: - sort:

and then to: - copyEmpty

or even to: - truncateWithElipsisTo:

How am I supposed to know if I change the original vs get a copy?

2011/1/7 <csrabak@bol.com.br>:

Em 07/01/2011 15:10, Nicolas Cellier < nicolas.cellier.aka.nice@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

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

+100 :-D -- Cheers, Peter On Sat, Jan 8, 2011 at 3:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:

What we will do is

deprecate copyFrom: from Object -> copyStateFrom: add copyFrom: in Sequenceable as self copyFrom: a to: self size

Stef

Comment #18 on issue 3436 by cesar.rabak: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 Your comments show consistency with your vision stated above about the need of an overhaul on the design of the interface (a.k.a. "API"), if you take the bulk of it. In order to sustain a civilized dialog, I need to concede you with this doubt. However, it seems to me this is flaring the judgment of proposal here: The method name has *copy* in it, hasn't? I _does_ return a *copy* of the object, doesn't? This issue #3436 is about: is it more adequate that a method called "copyFrom:" copies the state of an object or a part of one when it is a SequenceableCollection? Your other points have to be addressed elsewhere, be it in the mailing list as a preliminary discussion or as proposal here via a well formed issue. In order to avoid any doubts, my stance is that we adopt copyFrom: as an alias (or 'short cut') to "#copyFrom: start to: (self size)" in the most appropriate point of the Pharo object's hierarchy.

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