The most important function of encapsulation is separating public interface and internal implementation. For example, a library declares public functions available for users and private functions to use abstraction and implement functionality.

Of course it's not about syntax, it's about intent. In a language with no access modifiers using a foreign function starting with an underscore is automatically accepting that it is internal an has no guarantees as public API.

But encapsulation can be applied where it shouldn't. First, it is controversial to apply encapsulation in class or module level. If you're a part of the same codebase, what's the problem with breaking the contract? Famous problem arising from this is unit testing private methods of a class.

Second, it's controversial to encapsulate state. For example, there are no private structure fields in Zig[1]. Justification is that for a great control user needs to know the layout of the struct.

So to me it boils down to a decision of where to draw the line between API and internal. One could alas write programs as a bunch of small models each having own API. Or one could write the whole program in five huge classes, making private methods necessary to make differentiate "useful" ones.

The article has a bit of a "clean code" smell and lacks critique and shortcomings of lack and excess of encapsulation.

[1]: https://github.com/ziglang/zig/issues/9909

There is a fantastic concept called encapsulation, but OO encapsulation isn't it.

For an actual example of encapsulation, look at C stack variables. They are actually encapsulated within their function.

It's how the C function is able to operate as a black box - the true meaning of "encapsulation".

If you could write getter methods to expose C stack variables to outside callers, they would become just as non-encapsulated as OO class fields.