Channel Wires vs. Actor Framework?

[AristosQueue (NI)]

bsvare wrote:

Just so I can imagine it well, with this new feature, you can effectively hide all the event registration code into a channel?

Yep. The really frustrating part of this is that this would work in 2016 if I changed 8 lines of code. I just didn't realize which 8 lines until the gold master for this release was already produced. Sooooo close. 🙂 But we'll get there.

bsvare wrote:

it's not like you need to have while loops around the channel writer or event structure.

True, but they're generally much more valuable with the loops than without.

bsvare wrote:

Channels are really getting cool!

We in R&D like hearing that.

[Beutlich]

I like to think about applications in terms of components: a unit of independently deployable code. This can often map to loops in LV applications, although 'independent' can be tricky for custom structures.

Actor Framework was one of the first standards to truly provide a way of doing software components in LabVIEW. The two objects, the 'behavior' (actor) and the 'interface' (message), are a natural anatomy for a component. As an OOP solution, there is additional opportunity for problem solving through extension, overload and polymorphism.

Channels give a great way to connect loops, but they aren't a complete interface model. They are a transport mechanism like event registration or queues. Channels can be used to make an interface model, which could then be part of a component model.

So why use AF? Well, if your problem only needs simple/flat loops but multiple loops communicate with each other, then Channels may be good enough. Component-based coding takes more upfront design, and can slow down simple projects that need to be flexible, quick, and adaptable to changing needs. However, complex problems that need to be highly reliable often benefit by modeling the problem into subsections. The divide and conquer process creates regions of responsibility, and AF enables this division because it is a true component model. AF is generally better if you have a software problem that is interesting enough to draw pictures about.

As an aside, OOP thinking can provide simpler solutions to certain problems. So beyond the component advantages, AF inherits many of the traditional OOP advantages if you have a team able to leverage them. I personally see this as a nice to have advantage that doesn't always manifest, since not all problems are OOP problems.