Behavior is the interface/messages supported by the object, and data is an implementation detail that should not leak.
What's wrong with that?
And why are you pinning the blame on a whole paradigm from a problem caused by how a feature was implemented in a language renowned for being fundamentally broken ?
My question is, why is that necessary? Exactly what is the benefit, except for a tiny bit of convenience? Why is that better than functions that work on well-defined types? It adds coupling, and coupling adds complexity, so if I'm adding complexity, I want to know why it's better before I add it.
> And why are you pinning the blame on a whole paradigm from a problem caused by how a feature was implemented in a language renowned for being fundamentally broken
I think calling the JavaScript/TypeScript of today fundamentally broken is clearly untrue. But anyway, I'm not condemning OOP entirely because of this one feature in one language. I thought my comment made clear that I see this as just another in a long line of complexity I've seen that's caused by this unnecessary coupling of data and behavior.
When I think of the OOP paradigm, I really think of Java, which I would call more fundamentally broken than JavaScript. It's improved over the years by pulling in ideas like lambdas that loosen the straightjacket imposed by its broken interpretation of OOP. Half of the revered "design patterns" that we're supposed to learn for OOP are just to work around this coupling when it's getting in the way. Patterns, even if they're repeatable, are complexity. Have you implemented the Visitor Pattern [0] lately? I did it once and I will never do it again. That kind of stuff ties my brain in knots. If you like pointless puzzles, maybe it's fun, but for me it's just more and more complexity. When I just work with data and functions, most things become much simpler.
[0] https://en.wikipedia.org/wiki/Visitor_pattern#/media/File:Vi...
The benefit is subtype polymorphism via dynamic dispatch. When values flow through the program they carry the implementations of their operations with them, so a caller can operate on a value without knowing how that operation is implemented; a newly-introduced value can bring a new implementation of an existing operation, and existing callers can use that implementation without knowing that it’s new. There are other ways of achieving this, but OOP is a good one.
Subtyping/inheritance is sometimes convenient, but inheritance tends to be a constrictive way to reuse code that increases cognitive load. If B is a subtype of A, now, not only are the data of B coupled to the behavior of A, but the data or behavior of B _may or may not_ be coupled to A depending on whether B overrides A. More coupling. More cognitive load. And if you change A, you have to be careful that you don't break B. Then if you have C that's a subtype of B, then the cognitive load and possibility of unexpected breakage gets even higher. Ugh. No. I'm a simple-minded person. I don't want to think about stuff like that.
I see dynamic dispatch simply as a form of delegation, which can easily be accomplished functionally.
So, ultimately, again, I see these benefits as being _convenient_ but not _necessary_. And since all design decisions are trade-offs, I look at the downsides of the coupling and find that the trade-offs are simply not worth it.
Point us to a language that isn't broken in some way, an example of perfection that every language designer should aspire to follow.
And then show us how that perfection has helped that language to take over the computing world.