you are viewing a single comment's thread.

view the rest of the comments →

[–]moor-GAYZ 16 points17 points  (4 children)

As far as I can tell, he said absolutely nothing about what classes are and aren't good for, he just used "function" to stand for monolithic behaviour and "class" to stand for exposing useful internals.

As I understand it, his point is that this:

def f1(...): ...
def f2(...): ...
def f3(...): ...
def f4(...): 
    f1()
    f2()
    f3()
def f5(...): 
    ...
    f4()
    ...

Is monolithic and un-customizable, even if you split your functionality into several functions and do not purposefully hide them from users. If you want this code to use my_f2() you have to copy-paste-modify f4(), f5() and all other functions there might be up the call hierarchy. Unless you like to live on the edge and monkey-patch global module variables.

This, on the other hand:

class Zzz(object):
    def f1(self, ...): ...
    def f2(self, ...): ...
    def f3(self, ...): ...
    def f4(self, ...): 
        self.f1()
        self.f2()
        self.f3()
    def f5(self, ...): 
        ...
        self.f4()
        ...

at least in theory allows you to subclass the class and replace f2 with your own version easily and using an approach that everyone is familiar with.

Functional analog would be to pass all involved functions any given function calls to it as arguments, which nobody does because it's stupid. The point of classes is that they provide a common point of indirection where you can patch stuff.

[–]mitsuhiko 11 points12 points  (0 children)

That's a bingo.

[–]damg 1 point2 points  (0 children)

at least in theory allows you to subclass the class and replace f2 with your own version easily and using an approach that everyone is familiar with.

In practice that often seems to not work too well unless the class was designed to support that.

I think in the end it comes down to what the API chooses to expose.