No Dynamic Dispatch on class indicator in Actor Core

[rpodsim]

I was wondering why you didn't use Dynamic Dispatch on the Actor out terminal of the Actor Core.vi, you used Dynamic Dispatch every else. Just wondering if there is some advantage to not having the indicator terminal for a class Dynamic Dispatch.

[KuGr]

Have you tried to make it a Dynamic Dispatch output?  It breaks Actor Core.vi.

If you notice, the Do.vi accepts and returns the Actor, but not as a dynamic dispatch (Message is the dynamic dispatch), so it is only an object of type Actor, but no longer has the dynamic dispatch characteristic.

We could pass the Actor returned from Do.vi through a Preserve Run-time Class function, and get it back to a a dynamic dispatch, but to what end?  After Actor Core.vi is done, what happens to the actor?  Only a Send Last Ack.vi is called (sending the last ack to the creator of this actor) and that cannot be overriden (it has no dynamic dispatch terminals).

So, I suppose the advantage is that it is not required from the framework perspective.  If you are implementing an Actor Core and do something to the actor after the 'Call Parent Method' function, then perhaps you might need the actor to be Dynamic Dispatch again.  But remember, the Actor is essentially gone, it's queue is released.

Perhaps Stephen Mercer or Allen Smith, the framework authors and LV gurus, can explain this better, but that's my 2 cents.

[AristosQueue (NI)]

10 points and a bowl of gruel to KuGr for correct answer! 🙂

(Using the standard scoring system of my friends in college, if you don't like gruel, 10 bowls of gruel can be traded for a pot of lentils.)

One minor addition: Not making the output be Dynamic Dispatch output leaves the door open for the somewhat strange but possibly useful case where a Messsage's Do.vi actually swaps out the entire Actor for another Actor of an entirely different type. I haven't found a use for this, yet, but I thought it was interesting that the option exists.

If you want to do something after the Call Parent node returns, you are free to add a To More Specific node. Assuming you haven't written any tricksy messages that swap out the actor, you know that the To More Specific is guaranteed to succeed.

[rpodsim]

I don't think about the Do.vi not perserving the Run-time Class, that would explain why the output Actor could not be Dynamic Dispatch. I also never concidered that the Actor could be replace for another.

In my case I created a child Actor  that overrides the Actor Core to add an Initialize and Shutdown VI (both Dynamic Dispatch as I indend to use this child for inheriting instead of the Actor Class) before and after the Call Parent node. I am using the To More Specific Class to reCast to my child class. It's not causing any problems, that's just what brought the question up.

Which brings up a different question now, would the Preserve Run-time Class node be better suited for the casting instead of the To More Specific Class?

[AristosQueue (NI)]

> Which brings up a different question now, would the Preserve Run-time Class

> node be better suited for the casting instead of the To More Specific Class?

Not in this case... they're going to do the same operation and the To More Specific will peform faster.