Functional Global variables with polymorphic VI

[Ben]

"An API to an engine (or "Core" if you prefer) as polymorphic instances? "

As crossrule posted, we create a public wrapper for each Action of the AE which each wrapper exposes only the appropriate inputs for the selected action and then bunlde them when invoking the AE.

The polymorphic VI then allows you to easily choose which action you want to invoke.

The polymorphic-combined with teh wrapper for each action makes it easy to see what action is being invoked without the "Action" constant AND it allows the developers to mark the inputs that are REQUIRED as required on the FP on the appropriate wrapper.

This works nicely since the developer of the AE knows what inputs are required and the user of the AE can easily find out what should be used when the AE is invoked.

If you read to the end of the AE nugget thread you will find where Jim Kring shared that tid-bit with us years ago and wrappers around AE's are the default in my office. So much so that one of my co-workers wrote a Script to build the polymorphic VI automatically.

Ben

[JÞB]

OK, How do you deal with the Poly Con Pane restrictions?  All Instances with the AE Pane sans "Method"? (The action driving enum) and set unused to "Optional" is the only think I can think of.  But that seems nastier than just adding the *.mnu to the API folder and sticking on a function palette (for re-use) or just using an API Virtual folder in a project.

Why poly it up? In fact the effort is greater than not, too the point you script the poly!   You still need icon for the instances right?  And, what do you do to the developer that accidently unchecks the "Use Instance Icon box?" (I assume it would be painful enough that they won't make that mistake again)  I can't even think about what happen to a source distro with the default "Remove unused instances" option and other build specs could get as harry.  What are the provisos and caveats to this approach?

I'm going to learn something here

[crossrulz]

As always, Jeff, it depends on what you are trying to do.

If the only real difference between the "commands" you are sending to the AE (like what the OP described here), then the polymorphic just makes it a lot easier on the user of the AE.  They just have to wire up the data they want to send/store/process/who knows what.

Now for most of my application modules, the polymorphic is not the way to go.  I normally make a library that contains my module (or actor, to appease some of the CS people) and the communication scheme to it.  I make the AE (which manages the queue/user event/notifier) private and make a bunch of wrappers for each of the commands that should be sent to my module.  Those are made public.  So those who are trying to get my module to do something just use the command VI I made public.

[JÞB]

---

@crossrulz wrote:

Now for most of my application modules, the polymorphic is not the way to go.  I normally make a library that contains my module (or actor, to appease some of the CS people) and the communication scheme to it.  I make the AE (which manages the queue/user event/notifier) private and make a bunch of wrappers for each of the commands that should be sent to my module.  Those are made public.  So those who are trying to get my module to do something just use the command VI I made public.

---

Oh, I'm all down with the wrappers!  and yes, I scope my AEs so the developer MUST call through the API and the API members have approprate icons.  100% on board  (unless you WANT to be able to programaticly select method-  Null as an action comes in handy sometimes)

But, putting the API members in a Polymorphic vi?  Thats what I am not quite getting.  Doesn't that require exposing the unused terminals that could be left off the API members?  OK only the used termnals are "Required" and the unused ones are "Optional" (Siliently waiting for some schmuck to wire up anyway)  And I'll reiterate my ignorance of build spec caveats.

So what it the advantage to going polymorphic on the API? 

[Yamaeda]

In this case i assume it's the wrappers that's polymorphic? Most people dont use wrappers, in which case you can make the AE polymorphic directly.

/Y

---

@JÞB wrote:

Oh, I'm all down with the wrappers!  and yes, I scope my AEs so the developer MUST call through the API and the API members have approprate icons.  100% on board  (unless you WANT to be able to programaticly select method-  Null as an action comes in handy sometimes)

But, putting the API members in a Polymorphic vi?  Thats what I am not quite getting.  Doesn't that require exposing the unused terminals that could be left off the API members?  OK only the used termnals are "Required" and the unused ones are "Optional" (Siliently waiting for some schmuck to wire up anyway)  And I'll reiterate my ignorance of build spec caveats.

So what it the advantage to going polymorphic on the API? 

---

[PaulOfElora]

Yeah, I kinda don't get the concern/problem with separate data spaces.  I use poly FGV's, using variant attributes to store key name-value stuff.  The GET action does a Get Variant Attribute for a given name.  Each of the poly's subVI's stores a variant, but the connector in/out data types change to various data types (boolean, DBL, etc.).  Seems to work fine...