Comment #23 on issue 3436 by
[hidden email]: #copyFrom: is broken
http://code.google.com/p/pharo/issues/detail?id=3436IMHO, modifying a collection in place is and should remain an exception,
and restrict to the well known and explicit
- #add: #addAll: and variations
- #remove: #removeAll: and variations
- #replaceAll:with: #replaceFrom:to:with: and variations
- #at:put: atAll:put: and variations.
There has been also some recent additions #replace: and Squeak-only
#reverseInPlace.
These ones are less explicit though kind of imperative: #sort #sort:
#shuffle #shuffleBy:
There is also String class>>#translate:from:to:table: which modifies its
first argument... Used only as an optimization of asUppercase, asLowercase.
Same for collect:into:.
My feeling is that keeping as many core objects as possible stateless and
functional-language like is the best we can do wrt complexity.
Stateful operations should be restricted to things like IO (streams) or UI.
I once proposed to introduce self-modifying Point and Rectangle methods for
the sake of speed, and I am still amazed how soft the reactions were, this
sacrilege should have been anathematized!
So, the copy or not copy discussion is null and void IMO - at least until
we introduce lazy operations and start mixing stateful with lazy...
The discussion about naming consistency is valuable though, but standards,
cross-dialect and history counts too...
Since Pharo puts more weight on consistency than backward compatibility,
deprecating copyFrom: -> copyStateFrom: should be considered seriously...
_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Locked
