6 ms·

OOP definitely allows you to add both data abstraction and procedure abstraction. FP is opinionated concerning how one should abstract and OOP is fundamentally

OOP definitely allows you to add both data abstraction and procedure abstraction. FP is opinionated concerning how one should abstract and OOP is fundamentally less opinionated - for good or ill (that is pretty much the debate).

naasking 8y ago
> OOP definitely allows you to add both data abstraction and procedure abstraction. No it doesn't, not pure, typed OOP [1]. Unless you introduce dynamic types, then neither is more opinionated because you can just cast or dispatch at whim. [1] https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
- joe_the_user 8y ago
  In the vast majority of OOP language, the object allows one to do virtually anything behind the scenes with a bit of construction (plus of course functional programming is opinionated. There are a whole variety of definitely bad practices an FP programmer will point to as being disallowed by the FP). See: "Closures And Objects Are Equivalent" etc. http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent And https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean https://stackoverflow.com/questions/2497801/closures-are-poo...
  - naasking 8y ago
    Yes, because those objects are a fusion of OOP and ADTs. Pure OOP does not permit violating procedural abstraction. To summarise, FP provides good reasoning in the small, and OO is needed in the large to orchestrate stateful services via protocols.
    - int_19h 8y ago
      The paper that you're citing claims that "pure OOP" means "An object can only access other objects through their public interfaces". This feels like a very arbitrary definition to me, and one that does not correspond to what we deem OOP colloquially. Conversely, if the problem is "pure OOP", but most OOP that we actually use isn't "pure", then there's no problem.
      - naasking 8y ago
        Why is that arbitrary? Encapsulation is a core principle of OOP. Re: there being no problem, that depends. Pure OOP has advantages and violating the properties often sacrifice some of those advantages.
        int_19h 8y ago
        > Encapsulation is a core principle of OOP. That's exactly the assertion that I'd like substantiated. I don't think there's consensus on this. Sure, it's mentioned in the oft-cited "encapsulation, inheritance, polymorphism, abstraction" mantra - but so is inheritance, and yet prototype-based OO doesn't have it. Personally, I would say that the only core principles of OOP are object identity (i.e. objects are distinguishable aside from their state), and polymorphism via dynamic dispatch. Everything else is optional.
        naasking 8y ago
        There's a historical argument: encapsulation was in Cardelli's original object calculi, and part of every OO language of the time. There's also a conceptual argument: dynamic dispatch and object identity both require encapsulation. What do you think you're dispatching or comparing equality on if not hidden state?

naasking 8y ago

> OOP definitely allows you to add both data abstraction and procedure abstraction. No it doesn't, not pure, typed OOP [1]. Unless you introduce dynamic types, then neither is more opinionated because you can just cast or dispatch at whim. [1] https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

joe_the_user 8y ago
In the vast majority of OOP language, the object allows one to do virtually anything behind the scenes with a bit of construction (plus of course functional programming is opinionated. There are a whole variety of definitely bad practices an FP programmer will point to as being disallowed by the FP). See: "Closures And Objects Are Equivalent" etc. http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent And https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean https://stackoverflow.com/questions/2497801/closures-are-poo...
- naasking 8y ago
  Yes, because those objects are a fusion of OOP and ADTs. Pure OOP does not permit violating procedural abstraction. To summarise, FP provides good reasoning in the small, and OO is needed in the large to orchestrate stateful services via protocols.
  - int_19h 8y ago
    The paper that you're citing claims that "pure OOP" means "An object can only access other objects through their public interfaces". This feels like a very arbitrary definition to me, and one that does not correspond to what we deem OOP colloquially. Conversely, if the problem is "pure OOP", but most OOP that we actually use isn't "pure", then there's no problem.
    - naasking 8y ago
      Why is that arbitrary? Encapsulation is a core principle of OOP. Re: there being no problem, that depends. Pure OOP has advantages and violating the properties often sacrifice some of those advantages.
      - int_19h 8y ago
        > Encapsulation is a core principle of OOP. That's exactly the assertion that I'd like substantiated. I don't think there's consensus on this. Sure, it's mentioned in the oft-cited "encapsulation, inheritance, polymorphism, abstraction" mantra - but so is inheritance, and yet prototype-based OO doesn't have it. Personally, I would say that the only core principles of OOP are object identity (i.e. objects are distinguishable aside from their state), and polymorphism via dynamic dispatch. Everything else is optional.
        naasking 8y ago
        There's a historical argument: encapsulation was in Cardelli's original object calculi, and part of every OO language of the time. There's also a conceptual argument: dynamic dispatch and object identity both require encapsulation. What do you think you're dispatching or comparing equality on if not hidden state?