Wire Class To Case Selector

[SteveChandler]

It would be useful if we could connect a class wire to a case selector. You will be able to create a case for the children of the class. The internal connection for the selector will return the specific child class. This will eliminate the need to cast to more specific class inside of the case.

This idea came from this thread on Lava.

[JackDunaway]

How would you define cases? Type the fully qualified class name into the case label? Wire an array of objects into a new input terminal on the case structure? Does this only work for direct descendents? Just trying to drum up some conversation on this intriguing "poor man's dynamic dispatch".

[SteveChandler]

I don't think you would have to type the fully qualified name. LabVIEW should be able to figure out the first part so you would only have to type the name of the class. I was only thinking of direct decendents when I wrote this and I can not think of a use case for grandchildren. But that should be considered. (Edit: Maybe it only works for siblings?)

You can read the specific use case I had in mind by looking at the thread on Lava in the link above.

Summary: Daklus LapDog object messaging library returns a message name as a string and the message object. You dequeue a message, wire the name to a case structure, and inside the case you cast to more specific. This idea could eliminate all of that. There are probably a lot of similar use cases.

I guess this is a lot like a poor mans dynamic dispatch.

[kegghead]

I'm having a hard time with this one. First why would one want this? It doesn't seem like a "poor man's dynamic dispatch" it seems to do exactly what a dynamic dispatch does, albeit with some extra problems. If you're trying to chose a code block to execute based off the class type wired in, I'd argue that code belongs in the class and part of a dynamic VI and nowhere else.

[Daklu]

I appreciate the links Steve, but I'm not sure that kind of construct would be a very good addition to the language and I'm positive I don't want it added to the case structure.  If anything it would have to be a new construct.

Couple points:

-You'd have to use the fully qualified name.  It is possible for two classes from different libraries to inherit from the same parent and have the same file name.  Without a fully qualified name you're left with an ambiguous downcast.

-How would it handle child classes not loaded into memory at edit time?

-It actually wouldn't help out that much with the LapDog library.  You can create a unique class for every single message, but I expect most people will create message classes based on the message data types and use the message name to differentiate between messages.  You'll still need to case out the message name to execute the correct message handling code.

I can not think of a use case for grandchildren.

-The NativeType library classes are all grandchildren of the Message class.

[AristosQueue (NI)]

Duplicate of this idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-vi-server-reference-type-as-case-selector/idi-p/...

[AristosQueue (NI)]

For the record, this has been an idea within R&D for a while, it just hasn't been a priority feature. It addresses type testing when you don't have edit authority to add a new dynamic dispatch method to the class hierarchy. It wasn't useful when LV classes were first released, but the more published hierarchies we get -- where people have distributed libraries of classes -- the more the use case for type testing will come up.

> -How would it handle child classes not loaded into memory at edit time?

It wouldn't.

> -You'd have to use the fully qualified name.  It is possible for two classes from different

> libraries to inherit from the same parent and have the same file name.  Without a fully

> qualified name you're left with an ambiguous downcast.

If we made you type in names, you're correct. I've hoped that we could just drop LV class constants into the selection ring (essentially, use a picture ring instead of a text ring for selecting the cases).

> Does this only work for direct descendents?

No. There are two possibilities -- select the case that is the first case that matches based on the order of the cases OR select the most specific case that matches. So look for the class itself in a case, if not found, look for its parent, then its parent, and so on, until you check for the default case (which is the same type as the wire type).

[SteveChandler]

Daklu: You can create a unique class for every single message, but I expect most people will create message classes based on the message data types and use the message name to differentiate between messages. You'll still need to case out the message name to execute the correct message handling code.

You would be using the structure do do the cast and would not have to do it in every case. Just once for each message type. The message name could be part of the message data. As it stands if I have a hundred messages but only two types I still have to do the cast a hundred times. Not that I am thinking of creating a system with that many messages!

Aristos Queue: Duplicate of this idea:

I kudoed that idea. That one was partially what inspired me to propose this. But it only mentioned vi server references while this one only mentions classes. I did not see your comments in that thread that R&D was already talking about it and would not limit it to vi server references but would also include all hierarchies including classes. In the sense that you already said on the idea exchange that this idea would be included with that one I suppose it can be considered a duplicate. I am glad it is being discussed and hopefully it can bubble up the priority list.

And I really like using a picture ring in the case selector. I knew there was a better way than to type the class name.

[Daklu]

> I've hoped that we could just drop LV class constants into the selection ring.

Ahh, using a selection ring to guarantee type safety does make it something I can get behind.  (I didn't see how using a text-based case selector buys us anything other than slightly fewer mouse clicks.)

> As it stands if I have a hundred messages but only two types I still have to do the cast a hundred times

If you want to case out on message type before doing any downcasting, it's pretty easy to do.  It doesn't offer the type safety as the solution AQ is talking about but it does reduce the number of downcasts you have to drop on the BD.

[drjdpowell]

An image of what this idea might look like:

(made for a conversation on LAVA)

[David_Grucza]

I'll add my 2 cents with an apology for not absorbing the entire discussion: I think the primary purpose of Dynamic Dispatch is to move explicit case structures out of applications and into class hierarchies where LabVIEW handles the implicit case structures. If you wnat to return a value from the case structure you are talking about, your child classes will have to return the same data type, and that make the child class methods candidates for Dynamic Dispatch.