Actor framework strictly typed message queues?

Question

I'm just getting to grasps with the Actor framework.  I have implemented "similar" stuff in the past but I've approached it differently.
One thing I noticed was how easy it is to send a message to an incompatible actor core which results in a nasty run-time "to more specific class" error.
In the example project included with LV 2012, if I make the change shown below (OK, I am purposely senidng a wrong message on the given queue) I get no feedback from the IDE that an incompatible message is being sent ont he queue.  I think this has to do with the Message queues being for the base actor class.
Is there no way to have the actual queues more strictly typed so that we can say that Launching Actor Beta will result in a Queue reference which is only compatible with Beta (or children) objects or does this ruin the entire concept?  If possible, it would prevent the ability oto send incompatible messages completely which IMHO would be an enormous benefit.
The presentations on the Actor framework have shown huge benefits in strict typing of state machines (I'm referring to a couple of videos I've seen ont he NI website) but this element of things seems to be just a pokey as a string flatten and unflatten.  Send the wrong message to the wrong receiver and >bang< run-time error.
Just thinking out loud.
Shane.
Say hello to my little friend.
RFC 2323 FHE-Compliant

Answer 1

So two days and no reply...
I'm referring in essense to this part of the actor framework white paper as included with the template in LV 2012.
Messages from Callee to Caller
When a caller wants to send a message to the callee, the caller knows the type of the actor that it launched, so caller can easily choose the right type of message to send. But when an actor wants to send a message to its caller, the actor does not necessarily know what type of caller it has, so it does not know what type of message to send. Ideally, actors should be usable by many different callers. That maximizes code reuse. But making the actor truly independent of the caller requires more effort than is warranted for the situation. There are three techniques for defining messages that an actor sends to its caller
The High Coupling Solution—In this solution, the callee actor is written specifically for one type of caller, and can never be used with any other type of caller. In this case, the callee knows details about the caller's interface, so it may simply call the Send Message VI of the appropriate message. The message type is thus hardcoded into the actor.
The Low Coupling Solution—This solution works best when you have a known inheritance hierarchy of callers. In this solution, you create a matching hierarchy of callee actors. So suppose you have callers Hard Drive, Air Conditioner, and Fire Suppression, each of which needs to launch a Fan actor. You would create the Fan class, and then inherit from it Fan For Hard Drive, Fan For Air Conditioner, and Fan For Fire Suppression. Each caller launches its specific callee actor. All of the main Fan class' code is shared, but when it comes time to send messages, the Fan class has a dynamic dispatch method for doing the sending, and each of the children overrides that method to send the message appropriate for its caller. Each callee is still coupled to a specific caller, but the system as a whole is flexible to accommodate new caller types.
The Zero Coupling Solution—In order to make the callee actor independent from the caller, the caller must tell the callee what types of messages to send so the callee avoids picking a type itself. The best implementation of this solution has the caller record a message into the callee at the time the callee is launched. The callee provides a Set <Type> Message.vi method, where <Type> is the particular event that will trigger the message to be sent. The caller sets the exact message it wants to receive when this event occurs. When the event happens, the callee sends the chosen message, without any knowledge of what kind of caller is receiving that message.
Often the callee will define an abstract Message class that it uses as the input type for Set <Type> Message.vi. Callers create their own specific child of this abstract class. This setup gives the callee a way to set data into the message through the API defined by the abstract class, and gives the message a way to deliver that data in a form the caller can consume through the various overload and extension VIs.
Would it be possible to get some examples of the three different approaches to typing of the messages?  I'm aiming for the high coupling solution (with the option of slipping to option 2 through common ancestors) in order to provide the ability to detect wrong messages on wrong queues at edit time.
Shane
Say hello to my little friend.
RFC 2323 FHE-Compliant