Make "Launch Nested Actor" Dynamic Dispatch

[CaseyZS]

Is your feature request related to a problem? Please describe.
In our own, as well as other inherited projects, one of most common things developers want to do is to populate a nested actor with a common set of data before it's launched (think something like a reference to a logger). The most common solution to this I see is a wrapper around the native "Launch Nested Actor", but why not just make it dynamic dispatch so it could actors could inherit common behavior from an ancestor base actor.

Describe the solution you'd like
Make the inputs for "Launch Nested Actor" dynamic dispatch. Maybe requiring the overrides to call the parent class method is also necessary.

Describe alternatives you've considered
Sticking with the wrappers.

Additional context
N/A

[CaseyZS]

@niACS said he would reach out to SLM about reasons why this was decided against during the inception of AF.

[niACS]

From Stephen Loftus-Mercer:

Launch [Root|Nested] Actor are very deliberately NOT dynamic dispatch.

If you make Launch [R|N] Actor dynamic dispatch and you do NOT set "must call parent", then things are completely trashed... you no longer have a thread-safe bottleneck at all for actor launches; guarantees for Drop Message are gone; Last Ack is not guaranteed. In short, that's really bad, so let's not do that.

So I assume you want to make it dynamic dispatch AND set "must call parent". I think I need specific examples of what you're trying to do, because I think all the use cases are already covered. If you want to verify something is true of the actor object as part of launch, that's what Pre-Launch Init is for -- an error there prevents the launch, so you just need to override and check the settings of the object. Pre-Launch Init runs at a point where you can reserve resources from the rest of the system safely, without worrying that there are other actors launching at the same time. If we make Launch Root Actor be dynamic dispatch, you'd be doing checks that could be happening simultaneously with other launches (because even though it isn't reentrant, each of the overrides could be running parallel with each other). That means only some of the things that you might want to check as part of launch could be checked there -- that splits into two locations the "pre launch checks" code, and only some of them belong in one part, with the others being a subtle bug in edge cases.

I do not know of any use case for making those launchers dynamic dispatch. I'm happy to hear about one if you think you've found one.

[niACS]

The only use case I've encountered is Panel Actors, which have their own versions of Launch Actor. I note, however, that those launchers have additional inputs, so they aren't candidates for being dynamic dispatch overrides.

If we look at the use cases, we may find that this is more of a training issue, regarding actor life cycle and the proper use of Pre Launch Init.vi.

[CaseyZS]

Here's a use case that we've often encountered (and experience ourselves):

Say a particular application has a logger process that you want all actors to have messaging access to. For this application logging is viewed as a top priority and you don't want to risk it getting caught in an AF message bottleneck under any circumstances, hence the direct access. Access can be via an enqueuer or DVR or whatever, but for this example, let's say that whatever it is, it's wrapped in a "Logger API" class. It doesn't really matter the mechanism, but what's important is that the same Logger API class needs to be in every actor.

Now, if it's in every actor, we make the Logger API class a part of the private data in a base actor the for the entire application. To ensure that the class is given to every actor in the application, you'd probably want to access that class in the calling actor's private data and populate it in the nested actor's private data before launch.

If "Launch Nested Actor" were dynamic dispatch you could override that method in your application's base actor and make sure the Logger API class was always passed to a nested actor. You couldn't do this in Pre Launch Init because once you're there, you don't have access to the calling actor's private data anymore.

[ShockHouse5]

In this case, you already have a custom base actor. Why not just add private data to that Actor. Then you just use an accessor to set that data on your child classes prior to Launch Nested Actor.

[CaseyZS]

That's sorta the whole point of making Launch Nested Actor DD. You could implement this behavior in the Base Actor class and not have to duplicate the same code over and over whenever you launch a different nested actor. So in your picture above, the entirety of the block diagram would be the override of Launch Nested Actor and the call to the original Launch Nested Actor would be replace by "Call Parent Class Method".

[pettaa123]

I suggest to have Launch Nested Actor being overridable behavior via composition instead. Adding a specific logger to the inheritance tree would let you change the ancestor for every changing logger. From OOP perspective a Launch Nested Actor interface could be more desirable. Your derived classes would overwrite your launching behavior in their own pre launch init or actor core.

[r-good]

Prelaunch Init and Actor Core do not allow access to the caller's private data, so passing any configuration data from caller to nested before launch would not be possible here. This is why we have to have a custom launcher method that wraps Launch Nested Actor.vi

[pettaa123]

Launch Nested Actor is from my perspective nothing you want to inherit for the reasons I mentioned before. At least not for the mentioned logger case. I think Launch Nested Actor is the ideal candidate for composition instead. You can switch logger without touching your ancestor or add whatever you want to Launch Nested Actor while keeping coherence high by overriding only the Launch Nested Actor Strategy class.

[r-good]

I use the custom launch actor strategy that Casey describes. We have a DD method (though I believe only the base actor actually implements it) that we can add in the custom behavior we need for launching actors. We do not have a custom connector pane, so it would work for us to use the DD AF version if it was available.

I do however see the problem ACS brings up where custom inputs may be needed, which would make a custom solution the only way to do it (or accessors, but that leads to a lot of code duplication and more issues in my experience).

I think for my team and our use case, it would help to just override the framework method instead of having to use our own. We have had issues with using the wrong launcher before, as the AF version still works of course, but our custom data isn't transferred, so we get errors that are more difficult to find for us (the logger is part of passed data, so the logs are useless to find this error). But on the other hand, I don't know if this will work for all use cases, as Panel Actor demonstrates.

I would think that the safeguard could still be implemented by making the method require calling the parent, would it not?

[r-good]

We use this a lot really. Simple example is a configuration file, where our root actor is who finds it/saves the path to private data, then when other actors are launched, they have this populated in their PD so they can access the file. We have other bits of state and such that are managed the same way. Yes, I acknowledge there are other ways of doing this, but it's how we have settled on approaching it and making a custom wrapper for launching is how we maintain it.

I'm thinking through it more and I feel having the original Launch nested Actor.vi be DD would be a benefit. Not needing to remember the wrapper name we came up with, or not being able to mistakenly use the original would have helped us, especially when it comes to on boarding new folk to our actors

[niACS]

It seems like the only use case for a dynamic dispatch Launch Actor is to hand off data from the caller to the nested. The data in this case is fixed system-level data, and the actors all have some common parent. It seems like we can solve this with a new DD method on the parent class ("Transfer Parent Attributes") or some such, that gets called within Launch Nested. (I don't see a use case for a DD override of Launch Root - what are you transferring?)

Now, a question: on which actor do we dispatch?

Further, that question makes me realize that this option will only work on actors with common parents. That can be very useful (see Substitute Actor), but it's corner case.

[niACS]

OK, current proposal to answer this request is to add a new dynamic dispatch VI, Transfer Attributes to Nested Actor. This method would be protected, and would require calling the parent node. It will dispatch on the calling actor. The new VI will be called in Launch Nested Actor (only), and just prior to the call to Launch Actor Core.

It will take the Caller and Nested actor objects as inputs, and will return the Nested actor object and an error cluster. We are considering returning the Caller as well, which would allow for some update to caller data, but we are concerned that users might do something deranged like swap the Caller and Nested actors, so I'm leaning toward not.

Please share your thoughts on this proposal.

[r-good]

This would meet most of our use case. We do have a couple things that happen after calling Launch Nested Actor.vi, logging related, and that we grab the enqueuer we use to guarantee orderly shut down of the tree (its safe and responsible, I promise ;) ). So I'm trying to say that this will only meet half of what we do in our own Custom Launch Nested Actor.vi we built.

If there is going to be a require calling parent, why not allow for the override of Launch Nested Actor?

[negentropicdev]

Came here to say this when I saw the topic posted for gdevconna.

Please avoid must call parent as much as possible and rely on template pattern.

[niACS]

Please avoid must call parent as much as possible and rely on template pattern.

For the benefit of our wider audience, please elaborate on your concerns.

[negentropicdev]

Once you use dynamic dispatch directly with must call parent a handful of issues can be run into, especially with a base class override that would extend throughout an entire hierarchy, especially once intermediate layers are added into the hierarchy.

Different inheritance layers may be best served by having the call parent earlier or later and I've seen some heinous implementations where more data and configuration is added to the parent layers so child classes can better direct what happens at the parent layer because they need things to happen in a different order than other children. Despite all of this, Actor expects its behavior to happen and the behavior would best be served by having children layers do their class data transfers before AF actually does the launch but after it does some of the tracing and its own transfers.

The pattern I've been using is to have a static dispatch VI at the base layer (keep Launch Nested static dispatch) and then have a DD vi that can be overridden when children need to do their transfers. The static Launch Nested can do its trace logging and its own data transfers, then call the DD VI, then do the actual launch. With this setup there's no need to enable "Must Call Parent" since Actor can do its transfers outside of that DD VI.

It'd be quite difficult to have a sane mechanism consistent across layers of inheritance when the actor launching the async VI MUST be run last but there's nothing to enforce that via an override in children. Actor maintains control of the order of the things it cares about and mucking things up can be left to implementation layers.

This pattern is especially nice in this case because overrides aren't straddling the context change of unlaunched actor class in and message enqueuer out. With this pattern the override is MUCH simpler in that it's unlaunched actor in and still unlaunched actor out.

If another behavior needs to be exposed at another point in the launch process, another override can be added in somewhere else.

[Tom-McQuillan]

I agree with @negentropicdev 's approach.

Another key principle discussed at GDevConNA was that Call Nested Actor.vi must always be able to launch anything that inherits from Actor.lvclass. This means no edit-time or runtime errors.

[negentropicdev]

I said I'd put in notes from the meeting, here they finally are:

The consensus after quite a circular discussion is to not change anything about Launch Nested Actor.vi. Making it Dynamic Dispatch would enable cleaner code in some examples but create issues in others. Using the template pattern as I suggested opens a different can of worms and tends to make the hierarchy much more rigid in the kinds of nested actors that can be launched. All of these have a solution currently, which is the practice of creating a custom Launch Nested Actor or Launch As Nested Actor VIs that understand the specifics of the relationship and don't pollute the centralized code with uncommon needs. The drawback of this approach is there's nothing forcing anyone to use the intended VI and they can just use the regular Launch Nested Actor. In an environment where people are utilizing their own launch VIs this is terribly easy to document and is a far easier issue to deal with than the examples that shot down the various dynamic dispatch approaches.

The template pattern DD approach I suggested lead to a lot of counter-examples and questions:

• Is the DD on the caller or the nested?
• Some people need to have functionality after launching to handle checks and registration actions. Multiple new DD VIs?
• The DD VIs would have the generic base classes being passed in so overrides would need to potentially test out several To More Specific Class calls and maybe rely on fallback behavior to launch actors that aren't part of the same hierarchy.

The only approach that enables having strictly typed connector panes that are aware of more specific relationships is to continue with the practice of custom static launchers. Any of the DD approaches lead to generalization issues making some errors that could be caught at edit time move to run-time errors which are overall more effort to deal with.