LangWart: Method congestion from mutate multiplicty

[Oscar Benjamin]

On 10 February 2013 04:53, Mark Janssen <dreamingforward at gmail.com> wrote:
> On Sat, Feb 9, 2013 at 8:20 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Sun, Feb 10, 2013 at 2:54 PM, Rick Johnson
>> <rantingrickjohnson at gmail.com> wrote:
>>> 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.
>>
>> I agree. And we can go further and declare that there is only one data
>> [sarcasm]
>
> I have to agree with Rick, I think requiring the user to explicitly
> create a new object, which is already a good and widely-used practice,
> should be the Only One Way to Do It.

Why should I copy a potentially large data structure just to iterate
over it in reverse order? And why on earth would you want to remove
the more efficient ways of doing this?

> Guessing method names is far suboptimal to this simple, easy idiom.

There is no guessing. If the object has a __reverse__ method then it
specifically advertises that it knows how to create an iterator that
gives its values in reverse order. Otherwise __len__ and __getitem__
are used.


Oscar