Is Child VI helps when filtering objects by their type

[PrimaryKey]

Hejka Guys, I wrote a small VI that helps me a lot with actor architectures. Maybe you can benefit from it. Enjoy!

[PrimaryKey]

Before anyone asks where is this useful -> forwarding messages by type. 

[drjdpowell]

I had a similar idea years ago, but I never went with it.

[PrimaryKey]

Why not? What prevented you? Is this example useful?

[drjdpowell]

Back then was early in the development of “Messenger Library”.   As I used it though, I found I was happy with using string identifiers for messages, rather than Command-Pattern Objects (where this idea would be useful).  In the AF, this seems a good idea.

[AristosQueue (NI)]

You do type testing on messages often enough to want a subVI for it? It's unfortunately part of the Do.vi for Actors, but it's something I eviscerate from my code wherever possible, and it is almost always possible. I think I've got a few scripting VIs where I've got some type testing on control refnums, but that's about it.

If you do type testing frequently, I can see the value. I'm just surprised that it crops up that frequently.

[PrimaryKey]

It would be very nice to have type handling structure, an analog of case structure, that would cast to appropriate type and execute the code inside a single case. It would always select the class type that is closest in the inheritance hierarchy to the wired object. This structure could be used to create very robust and sleek dynamic typing without the need to having everything in one inheritance tree with a Handle.vi method for every class.

[drjdpowell]

---

@PrimaryKey wrote:

It would be very nice to have type handling structure, an analog of case structure, that would cast to appropriate type and execute the code inside a single case. It would always select the class type that is closest in the inheritance hierarchy to the wired object. This structure could be used to create very robust and sleek dynamic typing without the need to having everything in one inheritance tree with a Handle.vi method for every class.

---

It would.  Kudos here.

[AristosQueue (NI)]

If you can find me such a monstrous construct in any other professional programming language, I'm happy to take a look at use cases, but such a structure would be pretty much anathema to any good OO design. I realize LabVIEW is lacking interface types. Clamor for those, not for performance-heavy-hard-to-maintain type testing. You might as well go back to an enum and a variant -- you'll probably have better performance. Yes, I'm serious.

[PrimaryKey]

I will heed your advice -  Give us interfaces! 😄