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).
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.
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.
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).
Valid points, but not _the_ point. There is a big difference between allowing and supporting something.
OO languages _support_ hidden inputs and outputs as well as programming by mutation. They _allow_ programming in a functional style, but you will have to be inventive for it.
FP languages _support_ immutable values, referential transparency and all that. They _allow_ programming by mutation and hidden inputs and outputs, but you will have to be (sometimes very) inventive for it.
Starting points matter, but this depends on the programming situation. That's why you use OOP or FP where it is most appropriate or suitable. Neither OOP nor FP is a panacea. Neither OOP nor FP is the universal programming tool.
It has nothing to do with ownership. In FP, a function can only operate on data of a particular type. In OOP, a particular type (or class) gathers all the applicable functions (or methods) under one roof. Same difference.
The word "own" is pretty meaningless. What does "own" even mean? Classes and objects (thought of as "types") are an organizing principle for organizing your functions. If you didn't organize them in this manner, then you'd have the same functions that operate on the same data types, only they're scattered everywhere, just like in functional programming.
> the same functions that operate on the same data types, only they're scattered everywhere
???
OO is different because you have things like private variables. Meaning that only methods of an object's class can access the variable. So you now have a special group of functions that can access the variable. FP is not like that.
Is this guy talking about OO as described by smalltalk? Because he says that objects are bags of functions, not data, but in languages like java, c# and c++ objects are bags of both.
It's Uncle Bob who says objects are bags of functions. And this is not specific to Smalltalk nor dynamic languages. In Java, C#, and C++, objects are still just bags of functions.
The C++ family of languages isn't really all that object-oriented; it's practically a different (static, class-oriented) paradigm that takes some inspiration from OOP (mostly from Smalltalk) but more from C's particular implementation of statically-typed procedural programming, as a result they are based around structs-enhanced-with-methods rather than proper objects.
> 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.