Transform Abstract Actor Framework Message Class into a Concrete Message

[ARobertson]

I'd like to know if there is an accepted method to transform an abstract Actor Framework message class into an a concrete instance in a generic manner.  I'm trying to find a way to extend an Actor's functionality to broadcast messages to multiple subscribers without resorting to inheritance in order to provide the necessary subscriber tracking and publishing methods (something like a mediator pattern, I suppose). 

With the abstract messages created by the Actor Framework you end up with a parent abstract class message that actually contains data and a send method but no do method.  The concrete implementation inherits from the abstract class and supplies the do method.  During broadcast, I would ideally like to simply transform an abstract message provided by the publisher Actor into the concrete message requested by the subscriber while retaining the data from the abstract parent message.  I think I've actually managed to do this after reading up on the flattened class structure by swapping the bytes associated with the header and data portions of each message to essentially de-serialize the string into the expected object.  This is done in a generic way that leaves the mediator completely decoupled from both subscribers and publishers, but this seems to be breaking all sorts of programming conventions in my mind.  Is there a more appropriate means of achieving this generic functionality in LabVIEW?

[wiebe@CARYA]

"To More Specific" does this (and it's intended for this), and returns an error if the object is not the more specific class.

I'd stay away with flattening\unflattening. When you think you've got it working, there's another situation (for instance default values) that doesn't work.

[ARobertson]

Unfortunately that is not quite what I was looking for as I cannot go from an abstract class instance on the wire to a child instance the way you suggested in the attached image. If the abstract class was actually an instance of the child, this would work though it would seem to require the publishing actor to keep track of its own subscribers rather than delegating the transfers to a mediator.

Default values in classes are pretty annoying.  The workaround was to draw the parent hierarchy and associated version info from scripting nodes on subscribe.  This is relatively slow, though the header could be cached, and I am told it does actually work in a run-time environment.  I am sure there are other hidden issues with that process however.

[wiebe@CARYA]

The default class is the only weirdness when (un)flattening classes.  But there's padding involved in the class name so if it works for one class it might not work for other classes.

Not sure if I fully understand your use case. But I don't use AF...

You need to know the concrete class to cast to it. I don't see how it would help to cast to something the object is not. The error would help. If there is an error, it's not the concrete class. No error, it is the concrete class. This will get ugly if you have several concrete classes, unless you put them in a hierarchy. You only need to cast to the parent, and if it succeeds, polymorphism will do the rest.

Guess the main question is why you don't want to "resolve to inheritance". Seems to be exactly what you want.

[ARobertson]

The pad bytes to the class name can be taken care of with a little math. 

The idea was to see if it is possible to create an actor that can blindly route an abstract message with a payload to a subscriber expecting a concrete instance of that abstract class.  The concrete class would be dynamic dispatched accordingly to use the correct method that operates on the data provided in the abstract parent message's attributes. 

So a publisher would send an abstract message like "temperature data available" to a mediator.  One subscriber would request the same mediator to be sent a concrete instance of that temperature data available message called "check temperature" containing a payload whenever that temperature data available message is broadcast.  A 3rd actor might request a "display temperature" message that also inherits from the abstract message to be sent to it under the same conditions and perform different functions. 

A mediator actor can do this, but can it do do without explicitly unbundling the abstract message's payload and then rebuilding it as a concrete class via accessors? 

The other option is that each publisher just keeps track of all actors subscribing to a particular message, assigns data to a concrete instance of the subscriber's requested message, then sends it out for each subscriber.  This sort of functionality could be made common to several actors through inheritance, but I was trying to see if it could be done differently.