4 ms·
Don't agree with this. Usually, when people refer to "OO", they're talking about subtype-polymorphism along with OO 'encapsulation' of mutable state. These ar
by runT1ME 10y ago
Don't agree with this. Usually, when people refer to "OO", they're talking about subtype-polymorphism along with OO 'encapsulation' of mutable state.
These are very distinct from a FP approach. Note that in Scala, you can do 'pure FP' that looks very much like OO,
myData = oldData.change().map(x => x+1).filter(x => isTrue(x))
So you can see that the verb/object dichotomy sort of breaks down. In mutable 'OO' worlds, state is always implicit (because of this).
In the large, this is much harder to reason about! Even in Scala, a language which gives us OO, we (Verizon Labs) as an organization elected to lean hard on the FP side and shy away from the OO side of things.
- joelg 10y agoI agree the analogy is loose, but your comment raises an interesting question. It seems like we're talking about talking about two different definitions of what FP is. There's a strict, technical definition of "functions which have no side effects", which defines a coding style. But there's also a more subtle, ambiguous definition of "functions as the primary and most irreducible building block of code", which defines a coding philosophy. In my opinion, FP is the latter, so I'd actually disagree and say that your Scala code isn't FP, since it emphasizes transformations on an object. Maybe I'm in the minority here.
- runT1ME 10y agothe term 'function' refers to a true function, no side effects. So, when I say "FP", that's what I mean. >so I'd actually disagree and say that your Scala code isn't FP, since it emphasizes transformations on an object. What I wrote is no different than change(oldData) |> map(x => x+1) |> filter(x => isTrue(x) Often the '.' style in scala is literally syntactic sugar that will get rewritten to pass the data to a stand alone function.