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