@OneOfTheDans wrote:
Not sure I follow the issue with chained coupling. Do you agree it's standard practice to keep an Actor and its Actor Messages in one library (regardless the naming convention)? Then any Caller Library:Actor is already pulling in the whole Something Useful library, Actor, and dependencies. What additional coupling is added by including Caller Interface.lvclass in the same Something Useful library?
There wouldn't be, in the two actor scenario. But anyone *else* sending a message from Caller Interface will be linked to the library containing Actor. (That's where I was trying to go originally, but I was multitasking when I responded...).
I am also moving toward having most of my actor's messages in interfaces, with the interface + messages in their own library. With the interfaces outside of the actor's library, actors aren't coupled. And interfaces tend to have very little code of their own, so you end up with an actor library coupled with a set of interface libraries, and nothing else.
To your other point - do you have a practical example where multiple actors use the same interface? The closest I've come to that has always been naturally solved with inheritance, like a Base Module:Actor (with it's Caller Interface & messages) plus subclasses for My Module.lvclass. The best case I've seen for this was a fellow recently asking about 1 interface for every single message, so Actors could mix/match what they transmit and subscribe. I think this was for GUI work, in particular.
My current project, in fact. I have hardware sharing its data in a message, and copies of that message go to the UI element and to the logger. Several of my hardware actors send the same data message, in fact. (Though, to be fair, there is often value in having messages that are more specific, with respect to both the sender and the receiver.)
There are also use cases for wanting parent class behavior shared between actors that take radically different messages. In a case where I desperately wished for interfaces (but I was working in 2017), I wanted to create remote proxies for other systems, where each proxy had its own messages, but each managed a Network Endpoint in the same way. I also wanted to swap out my proxies with unit test stubs that took the same messages, but forwarded them to a test harness. Different core code + different messages = multiple inheritance = base behavior class + interface with messages.
