Classifying Actor Messages by their Intent -- Still a good idea?

[drjdpowell]

AristosQueue wrote:

And do you find yourself naming them "Three Integers One Boolean and An Instance of Animal.lvclass That Might Be A Child Instance.lvclass"? Because my messages very rarely have a single piece of data in them that would lend themselves to naming by the contents.

Do you really rarely have messages with only one piece of data?  I would have thought that the majority of messages should be one piece of data.  If I had an actor that ran a temperature sensor, for example, it would probably send commands that individually contained the sensor type, update rate, and of course the temperature.

[David_Staab]

drjdpowell wrote:

I would have thought that the majority of messages should be one piece of data.  If I had an actor that ran a temperature sensor, for example, it would probably send commands that individually contained the sensor type, update rate, and of course the temperature.

Actually, in my designs, most messages have several parameters. I would bundle all that information together into a single message object. That said, because maintaining messages (and creating anything but a simple concrete message class with no custom hierarchy) takes so much effort in AF, I tend to try to minimize the number of messages that have to be created for a design. But even if messaging were lighter-weight, I don't know that I would send status- or request-type messages with related information separately, because the receiving actor would have to cache information from them until all the messages arrived.

[AristosQueue (NI)]

drjdpowell wrote:

Do you really rarely have messages with only one piece of data?  I would have thought that the majority of messages should be one piece of data.  If I had an actor that ran a temperature sensor, for example, it would probably send commands that individually contained the sensor type, update rate, and of course the temperature.

They might be a single object, but that object is made up of multiple primitive values. Consider just an error cluster. Or just a waveform. Each of those has multiple pieces of data in it, even though they're packaged as a single object. Lots of simple data points get paired with a timestamp. Lots of simple commands get paired with a reply queue. Every message is tailored to the contents of that message. It's a mental model I find much easier to use rather than looking at the set of messages I have and trying to say, "Which one can I shoehorn this message into?" I suspect that I would end up using VariantMessage or FlattenedStringMessage frequently, if only becase that's what I observe in so many systems written by other LV programmers.

Keep in mind that I write very few of these systems for the real world myself. None of mine have ever been production code. I serve as a clearing house and aggregator for experiences from the various LV programmers who have asked me to look at their code or who have posted about their success stories. I have tried to make that clear repeatedly with the AF... I'll lay out the argument for why it should be done the way I have done it, but it is based on first-hand theory and second-hand experience... first-hand experience may very easily trump both of those. 😉

[Daklu]

AristosQueue wrote:

They might be a single object, but that object is made up of multiple primitive values. Consider just an error cluster. Or just a waveform. Each of those has multiple pieces of data in it, even though they're packaged as a single object.

The idea isn't to decompose your messages so they all send a single piece of data, or shoehorn all your messages into a preexisting message type.  The idea is to develop a reusable library of frequently needed message classes that you can use for most of your messaging needs without sacrificing readability.  Many of the messages I use have a single piece of data as the payload (and many have no payload at all,) but that's because my messages don't often need more than that.  If someone finds they need to send error clusters or waveforms frequently, I'd expect them to create an ErrorMsg or WaveformMsg class.  (Believe it or not I've never used waveforms much until a project I'm working on right now.  In this project's reuse candidates folder I have a Waveform and WaveformArray message.)

For more complex data types I typically put them in a class anyway, and it's easy enough to send the object as a LVObject message.

AristosQueue wrote:
I suspect that I would end up using VariantMessage or FlattenedStringMessage frequently, if only becase that's what I observe in so many systems written by other LV programmers.

Why do you think variants and flattened strings are used so much for passing data around?

[drjdpowell]

AristosQueue wrote:

I suspect that I would end up using VariantMessage or FlattenedStringMessage frequently, if only becase that's what I observe in so many systems written by other LV programmers.

Most of my messages are VariantMSG   Or ObjectMSG.  But I consider a single object or standard grouping like an error cluster or waveform to really be one piece of data.  Meaningfully a single "thing" outside of the context of just this one message.

[justACS]

David Staab wrote:

That said, because maintaining messages (and creating anything but a simple concrete message class with no custom hierarchy) takes so much effort in AF, I tend to try to minimize the number of messages that have to be created for a design.

Check out the Actor Framework Project Provider.  Among other things, it automates the creation of abstract messages.

It does not yet address the effort associated with refactoring an existing message.  I will be looking into that for a future release.

[AristosQueue (NI)]

niACS wrote:

Check out the Actor Framework Project Provider.  Among other things, it automates the creation of abstract messages.

It does not yet address the effort associated with refactoring an existing message.  I will be looking into that for a future release.

I wish we could have gotten some of that into LV 2013, but it's too late in the dev cycle, so it will remain a web download until 2014.