Dynamic dispatch for refnum of class

[infinitenothing]

I want the children of the "start run" class to be able to use this method but I'm noticing it doesn't let me set the queue refnum input to dynamic. Is there some other way to accomplish this? 

 

[Neil Pate]

What do you mean by dynamic queue reference? Is this something you can configure a queue to be?

[infinitenothing]

I'm referring to the dynamic dispatch terminal setting being unavailable (see below). I was hoping that I could wire a queue of ChildA or a queue of ChildB into that terminal and it would autoadapt (assuming ChildA and ChildB inherited from the StartRun class

[Neil Pate]

Still not getting you, sorry. You want to wire a queue of classes into a class terminal? Can you post your demo project? Just because the classes might have a hierachy surely that does not imply anything about a queue that may contain these?

You cannot set dynamic dispatch on a queue ref, can you???? (it is not a class itself)

Edited January 31, 2019 by Neil Pate

[infinitenothing]

I can post a project but I'm hoping this image makes clear what I want to do.

I want to be able to reuse my StartRun's Enqueue Serial Number in the same way that I'm able to use StartRun's Write Serial Number for its child's object.

 

Edited January 31, 2019 by infinitenothing

[Neil Pate]

Don't think you can do that, I think a queue ref cannot be dynamic dispatch, even if it contains a class.

I am not sure I really follow what you are trying to do, but could you flip the logic around a bit, and have the queue ref as like the second input terminal, and have a StartRun input as the dynamic dispatch input? So you Enqueu Serial Number class which you have shown would have the StartRun object as the primary DD input?

 

Edited January 31, 2019 by Neil Pate

[infinitenothing]

I'm not clear how adding another dynamic dispatch input solves my problem. The queue ref is still statically dispatched and will only take a queue of the parent class.

In terms of intent, I'm looking to improve reuse. Rather than writing an enqueue function in each child class, I just want one VI to handle that.

[Neil Pate]

3 minutes ago, infinitenothing said:

In terms of intent, I'm looking to improve reuse. Rather than writing an enqueue function in each child class, I just want one VI to handle that.

 

So then can the queue contain objects of the base class? Without seeing much more than this tiny bit of the solution it is a bit tricky to visualise a way forward.

[infinitenothing]

No, the queue only contains elements of the child class. I guess I could switch my queue over to the base class. It just seems a little better to use the most specific class possible and I don't understand why the refnum input can't be made dynamic

 

[Neil Pate]

5 minutes ago, infinitenothing said:

I don't understand why the refnum input can't be made dynamic

Because a queue is not a class. (I guess you know that, you are more trying say why is it not possible to be able to do this in the language...)

[infinitenothing]

Maybe I should have tested this before I posted but if I switch Enque Serial Number to a .vim, the broken wire resolves and everything works out. Neat! I wonder if there are any unintended consequences.

[smithd]

There should not be, adapting to type is all you want and thats what vims do. As pointed out, queues are not a runtime-dispatchable type in the same way you cannot dynamic dispatch off a boolean or an array. The contents are irrelevant. 

Its worth noting that vims support dispatching based on method name rather than class hierarchy. There are examples of using vims to make lvclasses act kind of like interfaces (ie if you have two separate hierarchies with a method "Get queue" which returns a thing at connector pane position 3, you can put that in a vim and it will adapt, including if that outputted thing has a different type).

As a side note, you can and should wrap the queue status and index primitives inside of a disable structure.

Edited February 1, 2019 by smithd