Hacker News Reader

Comment by willtim | Hacker News Reader

No, the biggest benefit is first-class modules. This is a feature that for example FP languages have struggled to incorporate. "Encapsulation" with OOP is a bit of a misnomer, as state is not encapsulated, it is just hidden. Such hidden state then interferes with composition. With true state encapsulation, a function can use mutation on the inside, but appear pure on the outside.

View on HN

I'm interested in this, since I thought the concept of encapsulation is maintaining, and hiding, state inside of an object. What's the difference between mutating state on the inside and hiding state on the inside? Aren't they practically the same?

> What's the difference between mutating state on the inside and hiding state on the inside? Aren't they practically the same?

You can mutate state on the inside, but still provide a "pure" mathematical function on the outside. For example, a root finding solver. The general problem/feature with objects, is that when a method returns, the object may be in a different state (and often is). Such state changes are hidden but not "encapsulated" as they still contribute to the global state of your application. In other words, the global variables are still there, you've just organised them into modules.

I don't understand your reasoning. What does prevent you from having hidden state within a first-class module? It's simply encapsulation at module level.

Objects don't have to have mutable state. And even if they do, it can be unobservable. This is true "state encapsulation" but the OOP definition of encapsulation does not require this. Such objects are still very useful as "first-class modules", i.e. modules that can be passed around and switched at runtime.

Reply on news.ycombinator.com