OOP vs. FP
medium.com
OOP vs. FP
1–10 of 30 posts
Re: OOP vs. FP
#2hmm, not so sure I agree to that extent.
[To me,]
FP is more about nobody owning the data. Everything operating on all the data. (Mostly) All data exposed and accessible.
OOP is about certain classes owning data and limiting exposure to that data.
Re: OOP vs. FP
#3I 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.
Re: OOP vs. FP
#4I 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.
I don't see that as much difference.
Re: OOP vs. FP
#5Valid 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.
Re: OOP vs. FP
#6I 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.
I don't see that as much difference.
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.
Re: OOP vs. FP
#7I 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.
I don't see that as much difference.
I think the difference becomes easier to see when you need to add new data types vs new functions
Re: OOP vs. FP
#8I 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.
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.
Re: OOP vs. FP
#9Is 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.
Re: OOP vs. FP
#10I 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.
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
Bar(Foo foo);
Bar(Foo &foo);
Bar(Foo *foo);
....