LangWart: Method congestion from mutate multiplicty

[Rick Johnson]

On Friday, February 8, 2013 9:36:52 PM UTC-6, Steven D'Aprano wrote:
> Rick Johnson wrote:
> 
> > The solution is simple. Do not offer the "copy-mutate" methods and force
> > all mutation to happen in-place:
> > 
> > py> l = [1,2,3]
> > py> l.reverse
> > py> l
> > [3,2,1]
> > 
> > If the user wants a "mutated copy" he should explicitly create a new
> > object and then apply the correct mutator method:
> > 
> > py> a1 = [1,2,3]
> > py> a2 = list(a1).reverse()
> 
> Oh wow, Rick has re-discovered programming in Python during the mid to late
> 1990s!
> 
> [...snip: long-winded, rambling, and sarcastic response simply to convey 
> that Python lists have had a "reversed" method for some time...]

Steven, i am quite aware of the Python list method "reversed" --which returns a copy of the current list object in reversed order--, my point is that these types of "copy-mutate" methods superfluously pollute the object namespace. Do you really want "method pairs" like these:

 sort, sorted
 reverse, reversed

Hell, why stop there:

 append, appended
 flatten, flattened
 insert, inserted
 map, mapped
 filter, filtered
 reduce, reduced
 extend, extended
 freeze, frozen
 set, sat|setted
 unique, uniqued

Is this really what you prefer? Where does the madness end Steven? At what point do you say enough is enough? And what happens if you fail to catch the infection early enough? Steven, this is a /real/ problem which has the potential to go viral!

My point was this: All mutate methods should mutate "in-place", if the programmer wishes to create a mutated copy of the object, then the programmer should /explicitly/ create a copy of the object and then apply the correct mutator method to the copy. 

 NO: reversed = lst.reversed() # Python
YES: reversed = list(lst).reverse() # Python

 NO: reversed = a.reverse() # Ruby
YES: reversed = Array.new(a).reverse!() # Ruby

This is about consistency and keeping the number of methods from spiraling out of control because we feel the need to automate /every/ task for the programmer, when in actuality, we are doing more harm than good.