My way of hiding implementation of an API

[tst]

---

@drjdpowell wrote:

---

As for what I think Steve's main point is - I tend to do the same only in cases where I'm really sure I will have a singleton. 

---

Actually, Steve's dislike of excess coloured wires cluttering the diagram, and this conversation on techniques, has inspired me to eliminate the wire from one of my APIs.

---

Oh, I also have other similar things which are not singletons, but they tend to have some kind of external identifier on the top level and a singleton below. For instance, I have a tag engine for I/O management and the VIs using it use the tag as an ID (so no wire, but there is something going into the top level API) and internally the API uses a singleton for the registration DB. I certainly have no objection for something like that, but I tend to use it only in specific circumstances. While it would be nice to have a custom wrapper for each VI for each static instance of X in my system, I also find that it's too much work to create and maintain. If we had something like Steen's recent idea about VIs that are linked to a template and can be updated when the template is, maybe something like this would be more viable.

[tst]

---

@swatts wrote:

I used that naming technique originally too, but every now and again it failed. This appeared to be when I was debugging, it changed the order in the call chain, I didn't look too hard into it, in typical lazy fashion I just swapped to a method that worked. It was LV2011

---

If I had to guess, I would guess this probably happened when you have dynamically called VIs. Such VIs become top level VIs, and thus appear at the end of the call chain.

[Yamaeda]

Looking at your implementation attempts it feels like poor mans OOP. If you make it an object in G# or LVOOP you can put your "global" in the object memory instead.

Ofc you'll need 2 wires, the object reference and the error wire, which can be hidden in a AE or a named queue.

/Y

[JÞB]

---

@Yamaeda wrote:

it feels like poor mans OOP.

---

EXACTLY!

That thar "Command" enum was once labled "Method".  My client got scared that I was writing OOP.  He did not comprehend OOP.  "Command" is much more "Aproachable" The difference..... Let's chat about that.......

[swatts]

but are you a poor man?

[Yamaeda]

---

@JÞB wrote:

---

EXACTLY!

That thar "Command" enum was once labled "Method".  My client got scared that I was writing OOP.  He did not comprehend OOP.  "Command" is much more "Aproachable" The difference..... Let's chat about that.......

---

Cramming to much functionality into an AE will get cluttered and messy rather fast, i'd say it's better to actually make OOP but keep hierarchy flat to get him used to it (no 3 level inheritance with linked objects).

My experience isn't the reading/interpretation of OOP that's the problem, but following/tracking down anything when you start debugging ... so if you use the base class for now it's pure code with direct connections, and later on you can add base classes or children. 🙂

/Y

[drjdpowell]

Some issues I've found, if anyone wants to try a similar thing:

1) When dynamically calling VIs using the ACBR noe with option 0x40 (pool of shared clones), the top level VI is always the same for each clone, so one then has to use the next one down the call chain.

2) "Call Chain" takes on the order of 10 microseconds to execute, which is a bit of a preformance penalty just to get rid of a wire, depending on use case.

[AristosQueue (NI)]

Someone suggested that I add a variant involving named references. The particular named reference implementation that I put here uses single-element queues. I have not built one for "action engine with local storage using the variant attribute table" nor any other type of name-lookup within the action engine. Might eventually, but not right now.