> Is there really so much difference between f(o), o.f(), and (f o)?
Yes, there is!
In the case of o.f(), o needs to know about f.
In the case of f(o), f needs to know about o.
Bar(Foo * foo); // how Foo::Bar() is implemented
Bar(Foo foo);
Bar(Foo &foo);
Bar(Foo *foo);
....
Alice extends class C with class A, which implements function a.
Bob extends class C with class B, which implements function b.
I have both Alice’s and Bob’s code, and I want to use both a and b. How can I do it?
Of course, there are ways to do it – notably multiple inheritance, if your language supports it – but the point is, in a functional language, this question never even arises. You just import the function definitions and use them, without ever having to think about the mechanics of it.
By the way, I’m not saying that this necessarily makes functional languages better (although I do tend to prefer them). I’m just pointing out that the difference is real.
Inheritance is there if you need it. It's an available option.
Anyone can bring it up, but "education" isn't relevant here. It's not what was discussed in the article, or the comments.
I'm not sure I see that.
If class A and B wrap a C by composition and expose, respectively, `a` and `b`, then I still very much have the choice of which I'm building. Perhaps less so if they wrap a C by reference, so the C can be reused (it's too late at night to be sure I've thought it all the way through).
'o' gives you capabilities to perform 'f'. 'o' can hide its data and only expose functions that it wishes.
With f(o), 'f' needs to be given permission to access 'o' internals.