12 ms·
> Really, what good reason is there to have data and behavior bound to the same object? Behavior is the interface/messages supported by the object, and data is
by simplotek 3y ago
> Really, what good reason is there to have data and behavior bound to the same object?
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 ?
- mark38848 3y agoWhich OOP language is not fundamentally broken? Smalltalk?
- pjmlp 3y agoAll languages have warts.
- xigoi 3y agoThat's a truism. Now, which OOP language is not fundamentally broken?
- pjmlp 3y agoAll of them, none of them. 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.
- dimal 3y ago> What's wrong with that? 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:Visitor_design_pattern.svg https://en.wikipedia.org/wiki/Visitor_pattern#/media/File:Vi...
- tomstuart 3y ago> 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? 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.
- dimal 3y ago