Community Nugget 4/08/2007 Action Engines

[ConnerP]

In regards to the "by reference object" issue, as I read more into the way LV handles certain design patterns, the actor framework is the way to go for by reference objects. Because then you do interact with the object (async VI) by passing around the reference to it's messager queue.

The only thing that complicates this is if you want to interact with the object/actor synchronously and you have to use the Send Message And Wait For Response, which is not really regarded as a standard application of the AF.

[wiebe@CARYA]

---

@drjdpowell wrote:

---

@rolfk wrote:

---

@Blokk wrote:

Beside wires, local variables, property nodes etc., there is another option could be considered, the "Set/Get Control values by Reference". This method is said to be fast,...

---

It's fast in comparison to the Set/Get Control Value by Name method, but definitely shouldn't be faster than a Value Property.

---

It's Set/Get Control Value by Index that is a method much faster than a Value Property.   It acts on the VI reference, rather than control reference, and I believe it changes the terminal rather than the control itself.  Thus it doesn't need the UI thread and can be faster.  Requires caching of the control's index, so is not so user-friendly.  One can use it, for example, if one had 300 controls to set via received messages.  Instead of 300 cases, one has a single case that uses a lookup table to find the index and sets the control by index.

---

One think to consider is that Set/Get Control Value by Index doesn't work when the VI is not running. So using it to set controls before a VI server run won't work.

[wiebe@CARYA]

---

@jfalesi wrote:

---

@rolfk

---

Value properties do not solve the problem of race conditions per se in comparison to local variables. It could be that the use of value properties can seem to solve it if you use the error cluster from them and in that way force a specific serialization of execution. But that is really driving out the devil with beelzebub, but not a solution.

---

+1 for the response

+1 for "driving out the devil with Beelzebub", which is my new favorite phrase.

---

Matthew 12:27:

And if I drive out demons by Beelzebul, by whom do your people drive them out? So then, they will be your judges.

or:

And if I by Beelzebub cast out devils, by whom do your children cast them out? therefore they shall be your judges.

A good source of quotes .

[wiebe@CARYA]

---

@ConnerP wrote:

In regards to the "by reference object" issue, as I read more into the way LV handles certain design patterns, the actor framework is the way to go for by reference objects. Because then you do interact with the object (async VI) by passing around the reference to it's messager queue. 

---

The way deal "by reference objects" is to not use them.

Actually I think the AF is a way to avoid BRO, by putting ASync code in an actor, to which you send messages. So there is no need for a BRO, since messages are the async communication mechanism.

AFAIC, combining AF with BRO is combining two solutions to the same problem, and by doing that you get the worse of both.

---

@ConnerP wrote:

The only thing that complicates this is if you want to interact with the object/actor synchronously and you have to use the Send Message And Wait For Response, which is not really regarded as a standard application of the AF.

---

Yes, doing synchronous stuff is a problem in an asynchronous framework... What, oh what, could be a solution for that...?

Any framework will complicate your code. That might be OK, as it might also same work (and therefore time (and therefor money))). No need to debate the usefulness of frameworks... 

For me, I like my solutions to be the simplest solution possible, and no FW (as we use the term in the LV community) will do that for me.

[ConnerP]

Wiebe,  I think you misunderstood. I meant that using actors eliminates the need for by reference objects, not that references should be used in the private data of actors. We are on the same page there.

I was averse to AF for the same reason you mention, but trying to delve into LVOOP and do things like making modules responsible for their own UI (via subpanels), running them async becomes a requirement and AF is exactly async OOP.

However, sometimes devices are required to fire in a synchronous manner, and if you choose AF, you are left using Reply Messages.

[wiebe@CARYA]

---

@ConnerP wrote:

Wiebe,  I think you misunderstood. I meant that using actors eliminates the need for by reference objects, not that references should be used in the private data of actors. We are on the same page there. 

---

Good. Indeed, I thought you mend that if you want to use BRO's, AF would somehow help.

---

@ConnerP wrote:

 I was averse to AF for the same reason you mention, but trying to delve into LVOOP and do things like making modules responsible for their own UI (via subpanels), running them async becomes a requirement and AF is exactly async OOP.

---

Guess when that happens, I have enough tools to solve it myself. AF might help there, but from what I see once people start making actors, everything becomes an actor. Can't really blame AF, it happens to SMs, PCs and (Q)MHs as well.

For me an actor is a class that, in the background, starts some parallel process. The object itself sends messages to that process. No user of the class needs to know about it. So the implementation is hidden, and that's how implementations should be (not saying AF doesn't do that).

My feeling about the AF is that those actors are more like modules. Nothing wrong with it, but I think it's too easy to make things way too complex, needing to solve problems that exist only because everything was made an actor.

Sending messages to modules sound familiar... In OO, calling an object's method is often called "sending a message" or "event". A framework that send messages to entities, around a mechanism that sends messages to entities, seem a bit double to me. Too complex for me.

That said, OO GUI's are a pain. Not sure though if the AF would help on the main problems. Implementing it in a normal hierarchy is tricky, but I bet with AF it still is tricky. We simply miss tooling in LabVIEW to do this properly. Like dynamic creation of front panels.

[drjdpowell]

---

@ConnerP wrote:

In regards to the "by reference object" issue, as I read more into the way LV handles certain design patterns, the actor framework is the way to go for by reference objects. Because then you do interact with the object (async VI) by passing around the reference to it's messager queue.

The only thing that complicates this is if you want to interact with the object/actor synchronously and you have to use the Send Message And Wait For Response, which is not really regarded as a standard application of the AF.

---

I also find "actors" largely supplants the use cases of by-ref objects.  But unlike the AF, my "Messenger Library" is designed to support using a variety of synchronous methods interchangeably with async ones.  I believe synchronous methods are much clearer and safer for startup/shutdown/reconfiguration operations, while async methods are for steady-state flow of data.

[Ben]

---

wiebe@CARYA...async becomes a requirement and AF is exactly async OOP.

---

Guess when that happens, I have enough tools to solve it myself. AF might help there, but from what I see once people start making actors, everything becomes an actor. Can't really blame AF, it happens to SMs, PCs and (Q)MHs as well.

For me an actor is a class that, in the background, starts some parallel process. The object itself sends messages to that process. No user of the class needs to know about it. So the implementation is hidden, and that's how implementations should be (not saying AF doesn't do that).

My feeling about the AF is that those actors are more like modules. Nothing wrong with it, but I think it's too easy to make things way too complex, needing to solve problems that exist only because everything was made an actor.

Sending messages to modules sound familiar... In OO, calling an object's method is often called "sending a message" or "event". A framework that send messages to entities, around a mechanism that sends messages to entities, seem a bit double to me. Too complex for me.

That said, OO GUI's are a pain. Not sure though if the AF would help on the main problems. Implementing it in a normal hierarchy is tricky, but I bet with AF it still is tricky. We simply miss tooling in LabVIEW to do this properly. Like dynamic creation of front panels.

---

Ditto that!

I have seen attempts at doing LVOOP up to the GUI and they are a nightmare to support if you were not the one doing the development. I presented one such project to my group as part of a "good bad ugly" presentation and the LVOOP all of the way to the top was "bad".

Re: Actor Framework

Craig Larman in his book called them "Active Objects".

An example is the code that talks to the credit card company to process transactions made at a Point of Sale cash register application. The cash register can still work if the connection to the credit card company is down via cash. The object that interacts with the credit card company accepts requests when it running and passes the transaction as needed. The cash register does not have to maintain the connections etc. It sends message to the Active Object and accepts responses.

A DAQ engine could be an Active Object running its own thing, accepting requests to change state, configuration or stream updates from a GUI or a process control application.

I am not a LVOOPer so feel free to correct what I said if that is wrong.

Ben

[drjdpowell]

---

wiebe@CARYA wrote:
In OO, calling an object's method is often called "sending a message" or "event".

---

That's a very poor analogy.  Sending messages or events in real life are asynchronous, non-blocking things, while a Call is a synchronous blocking thing.  And we already have a better analogy, it's a "call", as in "call on someone to do something for you".

[wiebe@CARYA]

---

@drjdpowell wrote:

---

wiebe@CARYA wrote:
In OO, calling an object's method is often called "sending a message" or "event".

---

That's a very poor analogy.  Sending messages or events in real life are asynchronous, non-blocking things, while a Call is a synchronous blocking thing.

---

I think the term event for call on a method is especially used in Java. In Java, that class does not have to run in the same executable, or even on the same machine. So in a way it could be an actor, but as a build in OO feature. I could be wrong, not into Java that much.

I'm sure I've seen it being used several times, but can't find any references right now. Event is used for to much things to get good search results.

An object can be made that act like an actor (let the init start a parallel message handler). Then sending events to it can be done by calling a method. If the "event" is Async, the method simply finishes like sending a message. If it is synchronous method, an event or message based system would also require a "call and wait for reply" construction. I prefer to keep that logic in the class, so it's encapsulated and users don't have to care about the implementation, while keeping the option of inheritances. I'm sure any useful framework will sell their features like this, but for me this feels right at the moment.

---

@drjdpowell wrote:
 And we already have a better analogy, it's a "call", as in "call on someone to do something for you".

---

Yes, I'm not a fan either.