Em 07/01/2011 18:17, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com > escreveu: 2011/1/7 : [snipped]
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?
Here is what I mean: I agree that #copyFrom: is ambiguous and could be renamed, with all deprecation precautions.
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).
But concerning #copyFrom:to: I think this name is a non issue for code readability.
Which I also agree, and add that it helps to keep the API as unambiguous as it gets.
I decided to play advocatus diaboli just to push a bit absurdness of this ubuesque thread.
It may sound like because we're thinking only in our crib space. The OP brought a point which converges with other threads in this mailing list about the difficulties an [Smalltalk] aficionado incurs when trying to show Smalltalk to people who already know present technology languages and environments.
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 ?
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. And to avoid lengthy and unnecessary follow ups on this: I don't see any problem on this, because Smalltalk (and Pharo in particular) makes this easy enough to do.
So no, I don't suggest to drop the copy though it's not strictly necessary, nor to append an Index to the name.
Great! ;-)
Who never browsed senders of such message in squeaksource code base could have such a foolish idea.
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...
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.
Right we should not guess, but it is not the whole story. There is some ergonomics in a well designed interface of the APIas put in the issue tracker. Names should be as consistent as possible and be concurrent to present programming practices. This will ease the way people learn and think in the programming language.
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.
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:
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 ?
I agree with the later, but not with the former: could aString first return a String or Character?
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.
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!? -- Cesar Rabak