Typing of actor messages

[Intaris]

I've already posted on the NI forum about this, but here goes.

How can we go about implementing the varying levels of coupling outlined in the Whitepaper delivered with the peoject in LV 2012.

I would be interested in how to implement a robust way to have multiple actor and / or message hierarchies which are strictly typed at edit-time.  That is to say, we don't get any casting errors at run time because which actor accepts which messages is clearly defined.

I can imagine this with a flat actor hierarchy and a tiered message hierarchy but how to go about it with multiple inherited actor branches and multiple inherited message branches (which mirrors the actor branching).  Each actor should only be able to receive it's own messages plus it's ancestors.  Passing a wrong message should give a broken wire.  Obviously, there could be several actual objects on each level of the class hierarchy, each with different functionality controlled by dynamic dispatch.

Actor:Car

Actor:Car:Ferrari

Actor:Car:RangeRover

Message:Paint

Message:Ferrari:Red

Message:RangeRover:Green

I should be able to send the Message:Paint message to all three actors.  I should be able to send Message:Ferrari:Red ONLY to the Ferrari actor and likewise the Message:RangeRover:Green ONLY to the RangeRover actor.

How to go about this in reality?  I could of course have several derivatives of Ferrari (Testarossa, Enzo and so on) and also several derivates of Red (Metallic, flat, striped or whatever).

I can only get the required functionality by actually implementing a method with a different name on each level of the Actor hierarchy.  That is to say I use a different method to send messages to a Ferrari than to a Car than to a RangeRover.

Any better ideas?

Shane

[Intaris]

In addition:  The only place I can see where this might be possible would be in the Send method for any given actor.  Referring to the project template included with LabVIEW 2012 (I have named the actors Alpha and Beta) I need to have an input into the "Send Beta Message" VI of the Type "Beta Message" to allow only Beta Messages and their ancestors to be sent, right?  At the moment it simply has a constant on the BD but replacing this with a control connected to the connector pane would solve that problem).  Wouldn't this prevent me from passing any messages "Beta Messages" may have inherited from?

I don't see the clean solution to this.  Am I asking for too much?

Shane.

PS Do I maybe need to reverse roles and have the messages essentially send themselves to certain allowed actor types?

Actor:Car

Actor:Car:Ferrari

Actor:Car:RangeRover

Message:Paint.Send accepting an actor type "Actor:Car" will work for Actor:Car, Actor:Car:Ferrari, Actor:Car:RangeRover plus any children

Message:Ferrari:Red.Send accepting an actor type "Actor:Car:Ferrari" will work for Actor:Car:Ferrari and its children ONLY

Message:RangeRover:Green.Send accepting an actor Type "Actor.Car.RangeRover" will work only for Actor:Car:RangeRover and its children

PPS The not-very-nbice thing about this approach is that I need a DIFFERENT VI call to send Message:Ferrari.Red and Message:Paint to the same actor.......  the .Send VI is not allowed to have different object types on the FP....

[Intaris]

Thinking about this more I realise that Message:Ferrari is essentially an abstract class with all ACTUAL messages being children, thus having Message:Ferrari as a common ancestor.

[Intaris]

I have managed to get something remotely similar up and running but I had to make the Actor.vi in the Actor.lvclass protected instead of private so that I could  call it in my actor and put a wrapper around the enqueue object to allow for stricter typing.

This way I cannot send an Alpha message on the beta queue and vice versa.  Will post info on further progress.

[AristosQueue (NI)]

Intaris: You want to check out Dmitry's work in this whitepaper

       https://decibel.ni.com/content/thread/13739?start=0&tstart=0

and the ensuing discussion. Dmitry's work creates an interface such that the only things that can be sent to an actor are messages the actor could receive, but it comes at a fairly steep cost, and the ensuing discussion discusses ways to do the same but with less overhead. (My own early posts in that thread are kind of disjoint... it took me a while to figure out what he was attempting... some days I'm slow on the uptake.)

[Intaris]

I've just given Dmitry's psots (and your replies) a bit of a read.  Although my and his requirements overlap a little, my concerns regarding security are less than his.  I find the API way to be too inflexible for the way I program (Mileage may vary for others).

Dmitry refers to a staggered hierarchy of messages in one of his later posts, this is essentially what I'm getting at.  I've gotten a pseudo-workaround going at work and I'll try to get it up and running.  It adds strict typing of the messages without anywhere near the overhead of Dmitry's architecture.

I'll see how far I get and I'll post back later.

Shane.