12-19-2013 03:34 PM
Basically I find myself sometime just creating one message with only one do method for all my actions that an actor should do. Just like the old way with commad and data clusters i just handle what the actor is supposed to do in case structure in one message.
I find this to make everything much more readable + when something is needed to load dynamically I can still use dynamically loaded messages that handle something else. I also found this to increase readability and decrease overhead of the project.
What do you think about this approach? Shouldn't we try to promote this aproach?
12-19-2013 03:57 PM
Do your method then look like a big case structure? I don't agree that it would be more readable, just readable in a different way. I group methods in my project that are the action in the Do.vi and it is readable from the project view. You discover the interface to the actor by looking at its messages not by looking at a enum for a single message.
My $0.02.
Phoenix, LLC
CLA, LabVIEW Champion
Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!
12-19-2013 05:12 PM
Piotr_Kruczkowski wrote:
What do you think about this approach? Shouldn't we try to promote this aproach?
No, I don't think this approach should be promoted.
Currently in the Labview community there are two main messaging paradigms for actor-oriented programming: Name/Data messaging and Command Pattern messaging. Each has advantages and disadvantages. Though the Actor Framework supports Command Pattern messaging natively, you can (as you have discovered) implement AF applications using the Name/Data paradigm under the covers.
The question is, why bother? Combining the paradigms doesn't give you the best of both worlds--it gives you the worst. If you prefer the readability and simplicity of Name/Data messaging, I'd recommend not using the AF and just writing your own actors. Your application will be much simpler in the long run.
12-30-2013 11:39 AM
Considering this is one of the big bugs that we set out to fix in the design of the AF, no, I don't think it is an approach to consider. 🙂
These were issues that I saw repeatedly causing problems in user code. Any downsides to the message classes of the AF are, in my opinion, completely dwarfed by the downsides of the "one message for everything" approach.
12-30-2013 05:30 PM
AQ's response is actually the best concise description I've heard of the value of actor framework over the clustersaurus. This is getting copied & pasted...
01-03-2014 12:14 AM
Awesome reply AQ, I'll use that in some of my teaching the AF as well. Its a common question. And Ben, I am definitely going to borrow your term of clustersaurus, I using call them the mothercluster, but some people take that a bit too negatively, even though I like it.
01-03-2014 07:22 AM
AristosQueue wrote:
Or you use a variant instead of the giant cluster, which means you have substantial memory copy overhead and the performance hit of testing the type to cast it back to its original data (not a cheap operation).
Side question (as I mostly uses Variant messages): what "substantial memory copy overhead"? And why would one be "testing the type"?
01-06-2014 04:00 AM
AristosQueue wrote:
- You lose the independence of the Do.vis on large projects where multiple developers are editing. When everything is one VI, you have to make changes to that one VI and you can't selectively roll back the changes to a single message.
- You are restricted to a fixed set of messages -- you can only handle those messages whose strings are pre-defined for you. A third party creating a custom message with its own handling routine is really tricky to do (it involves opening VI refnums in some weird ways).
- If a given message isn't used in a project, its code can be eliminated during AppBuilder, unlike the code being all built into a case structure.
I hadn't really appreciated this about the AF before. In my string-message based actor-like processes, the set of possible strings is what I think of as the "API" of my actor, and that this API "belongs" to that actor code module. But with the AF, it is really the public methods of the Actor's class that is the API, and the messages that can be sent to the actor are really code blocks that can belong to the components comunicating to the actor.
A Poll: How to people who use the AF mentally view the messages they send to an actor? As "part" of the receiving actor, or as part of the sending code?
01-08-2014 02:53 PM
Being able to route messages to dispatch handlers on other message contents than just type is highly desirable, as is having dynamically-typed message payloads (or no payloads at all, for a significant if not majority set of messages). For this reason, I fully endorse the sentiment, though not necessarily the implementation (cluster of string/LVVariant as the Message), of the original post.
Though, there are merits to statically typed messages and dispatching on type. Application domain might dictate which is clearly more desirable, though I can say for my applications >90% messages are dynamically-typed, where codebase agility is reason enough to justify loss of static type checking, etc...
01-08-2014 03:00 PM
drjdpowell wrote:
A Poll: How to people who use the AF mentally view the messages they send to an actor? As "part" of the receiving actor, or as part of the sending code?
I don't use AF for production code, but I view messages as being "part of" the documentation of an API, which then has the concrete implementation of business logic on the receiver-side and the concrete implementation of message construction client-side.
Sometimes this message type manifests itself as a data structure defined in the language's type system, and sometimes the client of that API is in the same language and can use that type. It's awkward in LabVIEW to designate "ownership" of this message to the API, especially if they are both encompassed by an LVLIB. Briefly, namespacing in LabVIEW is broken, since it also forces static linking (e.g., it's highly undesirable to statically link API business logic to the API's calling clients).
In this case, it's best to construct that message in the "global namespace" (e.g., none at all, by not being in a library), or through a dynamic type (such as a stringly-typed structure such as JSON or XML) to promote decoupling. These are fundamental problems with LabVIEW today, currently irreconcilable in an "ideal" way.