[Tutor] decomposing a problem

[Cameron Simpson]

On 26Dec2018 01:06, Alan Gauld <alan.gauld at yahoo.co.uk> wrote:
>On 26/12/2018 00:00, Avi Gross wrote:
>> great. Many things in python can be made to fit and some need work. 
>> Dumb example is that sorting something internally returns None and 
>> not the object itself.
>
>This is one of my few complaints about Python.
>In Smalltalk the default return value from
>any method is self. In Python it is None.
>self allows chaining of methods, None does not.
[...]
>Smalltalk uses this technique so much it has
>its own code layout idiom (Pythonised as
>follows):
>
>object
>   .method1()
>   .method2()
>   .method3()
>   ....
>   .lastone()

While I see your point, the Python distinction is that methods returning 
values tend to return _independent_ values; the original object is not 
normally semanticly changed. As you know.

To take the builtin sorted() example, let us soppose object is a 
collection, such as a list. I would not want:

  object.sort()

to return the list because that method has a side effect on object.

By contract, I'd be happy with a:

  object.sorted()

method returning a new list because it hasn't changes object, and it 
returns a nice chaining capable object for continued use.

But that way lies a suite of doubled methods for most classes: one to 
apply some operation to an object, modifying it, and its partner to 
produce a new object (normally of the same type) being a copy of the 
first object with the operation applied.

To me it is the side effect on the original object which weighs against 
modification methods returning self.

Here's a shiny counter example for chaining.

    thread1:
      print(object.sorted())
    thread2:
      print(object.sorted(reverse=True))

The above employs composable methods. And they conflict. When methods 
return a copy the above operation is, loosely speaking, safe:

    thread1:
      print(sorted(object))
    thread2:
      print(sorted(object,reverse=True))

Cheers,
Cameron Simpson <cs at cskk.id.au>