4 ms·

Saying OOP is anti-modular is like saying operands are anti-functional.

by toddh 16y ago

loup-vaillant 16y ago
Class based programming traditionally relies heavily on mutable state. Remove or severely limit mutable state, and most of us will stay it's not OOP any more. And pervasive mutable state is anti-modular. http://www.loup-vaillant.fr/articles/assignment http://www.loup-vaillant.fr/articles/assignment
- TimJYoung 16y ago
  Nothing in OOP says that object state must be mutable. It's just as simple to have objects that always maintain their instance pointers and internal state separate from one another and use message passing for transforming that state. Such an architecture is completely capable of running on multiple cores without too much context switching or other synchronization overhead issues, especially if the object message queues are lock-free. However, one of the keys to such an architecture is making sure that there are no shared sub-allocators being used by the RTL for memory allocation.
- toddh 16y ago
  Shared state is anti-concurrency, but objects don't share state, they hide state behind well defined interfaces which is inherently modular. Actors and objects work together beautifully. Objects handle the behaviour and the Actors separate out threads of control. It all goes to hell when stated is shared, but that's a completely different thing.
  - loup-vaillant 16y ago
    > they hide state behind well defined interfaces which is inherently modular They expose mutable state through a well defined interface. Unless you're talking about purely functional interfaces, of course. And purely functional interfaces are rare in typical class-based code, especially C++ or Java code. Most programmers don't understand that when when a class exposes mutable state, it automatically becomes more difficult to use because you can make fewer assumptions about it. That's why it's anti-modular. And that's even before you try concurrency.
    - toddh 16y ago
      Concurrency is dependent on how threads run your code. Accessing an object's mutable state within a defined thread context has no issues at all. Accessing shared state across thread boundaries is the problem with concurrency. My guess is people are coming from a POV where concurrency is automatically handled by the system, in which case you would want certain properties, but when coding in a typical environment where care is taken it's not an issue.

Saying OOP is anti-modular is like saying operands are anti-functional.

by toddh 16y ago

Saying OOP is anti-modular is like saying operands are anti-functional.

Class based programming traditionally relies heavily on mutable state. Remove or severely limit mutable state, and most of us will stay it's not OOP any more. And pervasive mutable state is anti-modular. http://www.loup-vaillant.fr/articles/assignment http://www.loup-vaillant.fr/articles/assignment

TimJYoung 16y ago
Nothing in OOP says that object state must be mutable. It's just as simple to have objects that always maintain their instance pointers and internal state separate from one another and use message passing for transforming that state. Such an architecture is completely capable of running on multiple cores without too much context switching or other synchronization overhead issues, especially if the object message queues are lock-free. However, one of the keys to such an architecture is making sure that there are no shared sub-allocators being used by the RTL for memory allocation.
toddh 16y ago
Shared state is anti-concurrency, but objects don't share state, they hide state behind well defined interfaces which is inherently modular. Actors and objects work together beautifully. Objects handle the behaviour and the Actors separate out threads of control. It all goes to hell when stated is shared, but that's a completely different thing.
- loup-vaillant 16y ago
  > they hide state behind well defined interfaces which is inherently modular They expose mutable state through a well defined interface. Unless you're talking about purely functional interfaces, of course. And purely functional interfaces are rare in typical class-based code, especially C++ or Java code. Most programmers don't understand that when when a class exposes mutable state, it automatically becomes more difficult to use because you can make fewer assumptions about it. That's why it's anti-modular. And that's even before you try concurrency.
  - toddh 16y ago
    Concurrency is dependent on how threads run your code. Accessing an object's mutable state within a defined thread context has no issues at all. Accessing shared state across thread boundaries is the problem with concurrency. My guess is people are coming from a POV where concurrency is automatically handled by the system, in which case you would want certain properties, but when coding in a typical environment where care is taken it's not an issue.