11–20 of 98 posts
The downside of message passing is debugging. No call stack so you can't trace things back to their source.
I use an additional message parameter, automatically inserted and maintained by the framework, which is a list of the messages (FIPA style operation + parameters) from the originating agent forwards to the point of debugging. This gets voluminous and is gated by debug levels.
Your essay is arguing against a strawman of what "good" OOP is supposed to be. Your examples... >Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information. The getX() and setX() is an anti-pattern of good OOP. >Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. No, good OOP has c…
>I'm guessing your comments are based on seeing a lot of poor practices masquerading as OOP which affects what you think OOP actually is I personally feel that the current OOP model eventually devolves into the bullet points you listed given enough complexity. One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class. There's explicit coupling even when…
If you mean there is no formal/explicit OOP syntax in C++/C#/Java etc for a "message bus" or "queue" for a decoupled publish/subscribe type thing, you're right. Yes, Golang/Erlang have that concept a little more "baked" into the language.
But that's still orthogonal to the supposed OOP flaws you brought up.
The C++/C#/Java approach to the missing "message" functionality would be either to create a class with a managed buffer to "hold messages" for other classes to write or read from... or use a library that interfaces with an external messaging bus.
Your essay is arguing against a strawman of what "good" OOP is supposed to be. Your examples... >Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information. The getX() and setX() is an anti-pattern of good OOP. >Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. No, good OOP has c…
This needs to be tattooed in reverse on many developers foreheads so it's the first thing they read when brushing their teeth in the morning.
Earlier quoted context omitted.
>I'm guessing your comments are based on seeing a lot of poor practices masquerading as OOP which affects what you think OOP actually is I personally feel that the current OOP model eventually devolves into the bullet points you listed given enough complexity. One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class. There's explicit coupling even when…
>One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class. If you mean there is no formal/explicit OOP syntax in C++/C#/Java etc for a "message bus" or "queue" for a decoupled publish/subscribe type thing, you're right. Yes, Golang/Erlang have that concept a little more "baked" into the language. But that's still orthogonal to the supposed OOP flaws yo…
Yeah, I explicitly covered this. I don't feel like piling some 'controller' object on top of other objects necessarily accomplishes what I'm after.
But it does work and I've used the pattern plenty.
http://erlang.org/pipermail/erlang-questions/2009-November/0...
Joe likes to be funny, so don't get upset and confrontational about it.
The central idea is this I think:
---
I now believe the following to be central to the notion of OO.
- Isolated concurrent things
- Communication through message passing
- Polymorphism
---
Your essay is arguing against a strawman of what "good" OOP is supposed to be. Your examples... >Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information. The getX() and setX() is an anti-pattern of good OOP. >Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. No, good OOP has c…
>I'm guessing your comments are based on seeing a lot of poor practices masquerading as OOP which affects what you think OOP actually is I personally feel that the current OOP model eventually devolves into the bullet points you listed given enough complexity. One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class. There's explicit coupling even when…