[Pitarou]

I don’t wholly disagree with the article, but I think it overstates its case. In particular:

> 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.

[trendia]

Maybe I'm mistaken... but at least in C++ the implementation of Foo::Bar() is similar to Bar(Foo):

    Bar(Foo * foo); // how Foo::Bar() is implemented

So while Bar(Foo) could be passed as several ways:

    Bar(Foo foo);
    Bar(Foo &foo);
    Bar(Foo *foo);
    ....

there isn't really a huge distinction between the two except for syntax and locality within the source file. (That is, class methods are all defined in the class and can't be spread across multiple header files).

[nailer]

I don't see that as much difference.

[fantasticsid]

I think the difference becomes easier to see when you need to add new data types vs new functions

http://wiki.c2.com/?ExpressionProblem

[Pitarou]

Take a class C.

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.

[horrido]

Inheritance is not a strict requirement of OOP. In OOP, you can always use composition, in which case the question also never arises.

Inheritance is there if you need it. It's an available option.

[BoiledCabbage]

Yes, but in common discussion, noone when talking about OOP is referring to inheritence-less OOP. No common programming language uses it, few to no programmers practice it. OOP/w inheritance is the default item being discussed.

[horrido]

And why is "common discussion" technically relevant? This is not a fault of OOP but of education.

[BoiledCabbage]

You're talking about about OOP-B, everyone here is talking about OOP-A. OOP-B isn't really a part of what's being discussed.

Anyone can bring it up, but "education" isn't relevant here. It's not what was discussed in the article, or the comments.

[dllthomas]

> in which case the question also never arises.

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).

[cromwellian]

Maybe it's best to think about this in a capabilities-security aspect.

'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.

[girvo]

In Nim, with its unified function call syntax, there is no difference between them, which is pretty neat.