4 ms·
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
by 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 agoConcurrency 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.