Community Nugget 4/08/2007 Action Engines

[drjdpowell]

---

wiebe@CARYA wrote:

---

@drjdpowell

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.

---

You're describing "Messenger Library" actors, though "Init" is called "Launch Actor".  I sometime make functions to hide the detail of the messaging, especially for someone to use in non-actor code.  However, the flexibility of messaging patterns available in Messenger Library is lost, unless you define hundreds of such functions, so I usually just use the Messaging API directly.

[wiebe@CARYA]

---

@drjdpowell wrote:

---

wiebe@CARYA wrote:

---

@drjdpowell

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.

---

You're describing "Messenger Library" actors, though "Init" is called "Launch Actor".  I sometime make functions to hide the detail of the messaging, especially for someone to use in non-actor code.  However, the flexibility of messaging patterns available in Messenger Library is lost, unless you define hundreds of such functions, so I usually just use the Messaging API directly.

---

You mean the AF Message Queue API? I might look into that, but I usually get a queue working pretty fast. That API seems to do mostly the same?

When I start looking into those VI's, I'm inclined to say: "never mind, I don't need that":

[drjdpowell]

---

wiebe@CARYA wrote:

---

@drjdpowell

---

You mean the AF Message Queue API?

---

Sigh.   Of course I don't.

A problem we have in the LabVIEW community is that it is very difficult to mention the "Actor Model" without everyone thinking you mean the Actor Framework.   The AF is a framework that attempts to use the Actor Model of programming, but many of it's features aren't part of the model (like the "Command-pattern" messages).   "Messenger Library" is also intended to allow one to follow the Actor Model, but is otherwise quite different than the AF.   The AF's messaging API is very limited, having little more that "Send" and a (limited and very clunky) "Send and wait for reply".  "Messenger Library" is called "Messenger Library" because a its central feature is a powerful and flexible messaging API.  My "actors" are just VIs containing a Message Handler that uses the messaging API.

[wiebe@CARYA]

---

@drjdpowell wrote:

---

wiebe@CARYA wrote:

---

@drjdpowell

---

You mean the AF Message Queue API?

---

Sigh.   Of course I don't.

---

Good.

---

@drjdpowell wrote:

A problem we have in the LabVIEW community is that it is very difficult to mention the "Actor Model" without everyone thinking you mean the Actor Framework.   The AF is a framework that attempts to use the Actor Model of programming, but many of it's features aren't part of the model (like the "Command-pattern" messages).   "Messenger Library" is also intended to allow one to follow the Actor Model, but is otherwise quite different than the AF.   The AF's messaging API is very limited, having little more that "Send" and a (limited and very clunky) "Send and wait for reply".  "Messenger Library" is called "Messenger Library" because a its central feature is a powerful and flexible messaging API.  My "actors" are just VIs containing a Message Handler that uses the messaging API.

---

Well, I mentioned non-AF actors in this thread myself, but "message" was a bridge too far for me (again, almost weekend) .

But about that AF Message class (or any AF class I think?)... Isn't it weird a OO pattern suggest making a copy to change behavior? All this time I thought inheritance was the way to do that.

I really have to dig into AF at some point. Last time I gave up after just looking at some intimidating tutorial. There must be something to it? Pretty sure I understand what it is and that it's not for me. But I had similar thoughts about OO too. Although I thought OO was a good idea that I did not get.

[drjdpowell]

---

wiebe@CARYA wrote:
But about that AF Message class (or any AF class I think?)... Isn't it weird a OO pattern suggest making a copy to change behavior? All this time I thought inheritance was the way to do that.

---

Not sure what you're talking about.   If I were to use the AF, I would definitely be making use of inheritance for both messages and actors.

[wiebe@CARYA]

---

@drjdpowell wrote:

---

wiebe@CARYA wrote:
But about that AF Message class (or any AF class I think?)... Isn't it weird a OO pattern suggest making a copy to change behavior? All this time I thought inheritance was the way to do that.

---

Not sure what you're talking about.   If I were to use the AF, I would definitely be making use of inheritance for both messages and actors.

---

It's the comment in most AF VI's (and the image I posted earlier):

NOTE: Modifying this VI will change its behavior for all users of LabVIEW on this computer.

To prevent this issue, select File>>Save As and select Copy (Substitute copy for original) in the dialog box that appears. This action creates a copy of the VI that you can modify without affecting other users.

No way to educate people, IMHO.

[drjdpowell]

You're not supposed to change anything in vi.lib, period.  I think this is leftover from early days of the AF, where early adopters might experiment with modified copies of the library.

[wiebe@CARYA]

---

@drjdpowell wrote:

You're not supposed to change anything in vi.lib, period.

---

That's clear to you and me...

---

@drjdpowell wrote:

 I think this is leftover from early days of the AF, where early adopters might experiment with modified copies of the library.

---

Leftovers are terrible. I'd still advice a child over a copy! Anyway, I think they should change it, but it's not my cup of tea...

[jfalesi]

Leftovers are perfectly safe if reheated to the correct internal temperature.

[paul.r]

---

@jfalesi wrote:

I have a related observation/question: Reading some of the "patterns are anti-patterns" rhetoric on LAVA (https://lavag.org/topic/11603-labview-anti-pattern-action-engines/?page=2#comment-125006) and criticisms of design patterns on wikipedia (https://en.wikipedia.org/wiki/Design_Patterns), there seems to be the sentiment out there that patterns point out deficiencies in programming languages - in the sense that if you find yourself repeating a sequence of steps to implement particular functionality, maybe the language should be able to do that sequence for you. I mention this in regard to the Actor Framework <ducks rocks, stones, GoF bobbleheads>.

It seems to me that NI recognized the recurring use of queued-event-driven state machines with consumer/producers and addressed the issue by designing a framework around them. However, mentioning OO in the presence of LV developers - let alone AF - is often met with groans, pained expressions and projectiles. So the options seem to be: (1) The traditional perspective that if you think you need some of that OO stuff, you just haven't learned enough LabVIEW tricks yet (a.k.a. "you can do anything OO-like without OO in LV"); (2) Use OO patterns like the GoF intended and be grateful that they imparted their wisdom upon the masses; (3) Use the AF because it represents the lessons learned from repeated use of design patterns. 

Is there a repository of guidance somewhere that can walk one through the architecture process to determine if one requires a non-OO LabVIEW pattern, an OO pattern or the AF? Like, maybe a decision tree flowchart type thing?

One final thought: When it comes to architecture, LabVIEW is in a sense its own worst enemy - the language makes it so easy to just "start coding" and accomplish something useful that it almost seems antithetical to step back and think about architecture. But without an architecture, complexity can overwhelm utility. Anticipating when this is likely to happen seems to be the key to whole thing.

---

What experienced LV developers are you around that groan about using OOP? 99% of the code I write is OO, as is the case for most of the experienced developers I have worked with. The decision to use OOP or AF is never universal or black and white - OOP may be a good choice for one developer, and a terrible choice for another. If you're not experienced developing OO systems and have to start a new, time critical project, learning OOP as you go probably isnt the best decision. 

I find that using OOP makes my code cleaner and easier to understand and my development process faster. 

D'Oh, just realized the discussion is 2 months old and has long passed the post I was responding to.