I do a lot of bundling actor messages to interfaces and eventually stumble across sending a message to an actor that does not inherit the needed interface. This may happen when taking the wrong enqueuer from a cluster or whatever, but it gives no hint during design-time is sometimes is hard to find. Last time this happened to me, I wondered if I could not just make a subclass enqueuer, that is returned only from those actors that I choose (those that implement the according interfaces) and is used to speak with the actor, preventing me from using the wrong one. This is propably a bad Idea (like most things that interfere with the basics of the AF) and I can not do this, because the enqueuer class is hardcoded into the actor starters and its creation can not be overridden. But I can subclass the enqueuer class and store it where I want, and I can return it from my actor using a custom method, but this is pointless as long as I cannot somehow cast the actual enqueuer to this more specific class. So my more philosophical question is: May there be any good way, to bind the type of an actors enqueuer to the actual skills of an actor?

See https://forums.ni.com/t5/LabVIEW/Follow-up-questions-from-quot-G-Interfaces-in-LV-2020-quot/td-p/4043471

Actor Framework Discussions

Is there a way to create a more specific enqueuer for an actor?

Solved!

To introduce the middle layer:

Every actor class X would have two static dispatch methods: "Launch X as Root" and "Launch X as Nested" both take the actor as input (so you can launch descendant types) and output "X Enqueuer" that has all the necessary Send methods on it.

Every interface Y meant for an actor would also need a "Launch Y as Root" and "Launch Y as Nested" method and a matching "Interface Y Enqueuer", and if you ever wanted to send messages to something that implements both Y and Z interfaces, you'd have to create the combined "Interface YZ" that inherits from Y and Z and adds the "Launch YZ as Root" and "Launch YZ as Nested" methods.

All of that is scriptable.

In short, it adds a second class hierarchy that duplicates the actor hierarchy and the interface hierarchy, but it would prevent messages going to unsupported recipients.

There's a minor problem is what to do with the "Send Batch" or any other message that is added on. This approach rules out those add-ons or any other "create a message that does a composite of actor operations" because you can only send messages that are on the X Enqueuer type. This is a minor problem... we elevate Batch Message to always be part of Actor and then let devs create composite actions by hiding them inside Batch Message (a batch of 1 message where the Do has more complex actions).

The message classes still have to include the downcast check, because you still have to at some point get from a generic actor to the specific actor within the Do method, so there's no runtime savings. (Batch Msg could still smuggle in unintended messages, so the checks still have runtime value in that rare corner case.)

It's a fair amount of additional code. Do you think it would be a better architecture?