More interface functions in Actor Framework Project Provider

[CaseyZS]

Is your feature request related to a problem? Please describe.
Make it easier for developers to use Msg interfaces. It would be convenient if developers could, instead of creating a Msg associated with the actor library, to instead make a Msg associated with an interface library.

Describe the solution you'd like
Add an option in the AFMMP to create a Msg for an interface (and modify the existing "Create Message" item to be more clear that it's for the owning Actor).

If the "Create Message for interface" was chosen, it would prompt the user to add the Msg (and template payload method) to an existing interface (drop down list) or to create a new interface.

Describe alternatives you've considered
None come to mind.

Additional context
N/A

[niACS]

I'm going to argue against this feature request.

If the user selected Create Message for Interface, we'd have to track down every interface from which the actor (or any of its parents) inherits. If the user picks "new interface", we'd have to chain in the code to create it. Then we might have to add a method to the selected interface, and then the message.

From the user perspective, we go from a simple "click a menu item, get an artifact" paradigm to making them click the menu item, then navigate to the desired interface class, then maybe make a new interface class, then get the new artifact. More importantly, interfaces are part of the system architecture, and we may be asking users to make architectural decisions about their interfaces while making messages.

Plus, as an added wrinkle, you can inherit more than one interface with the same method. So who gets the message? Or do you create a duplicate method in a different interface?

How likely are users to make a mistake somewhere along the way?

[CaseyZS]

That's certainly good food for thought.

Regarding the first objection about tracking interfaces across the inheritance hierarchy - I don't think it's too challenging and something similar is done in Bowzer. But that issue notwithstanding, when I made the suggestion, I was thinking that the list of interfaces would only be those in the project. Maybe that's simpler, maybe not.

As far as the UX, I can see why it could be more cumbersome. Perhaps it could be in an "Advanced" sub-menu? I'm also not necessarily developing it as an add-on utility and, if it seems to get widespread adoption, then re-visiting the idea of making it a part of the official release.

[svelderrainruiz]

I am moving this to a discussion.