Why to use static dipatch member VI?

[Eugen Graf]

Why to use static dipatch member VI? It has only disadvantages to the dynamic dispatch member VI. Do it have less overhead for LV?

[shoneill]

QUOTE (Eugen Graf @ Jun 14 2008, 01:08 AM)

Why to use static dipatch member VI? It has only disadvantages to the dynamic dispatch member VI. Do it have less overhead for LV?

If you have a parent class where not ALL of the functionality should be overridden by child classes, the functions which should NOT be overridden are static dispatch.

You could, for example, have a group of child classes for manipulating data within a parent class but have a set of VIs for displaying the data which are independent of the child classes. I don't think I'm explaining this very well..... :headbang:

A Static dispatch VI DOES have less overhead, but the difference in negligable unless you're calling it tens of thousands of times per second.

Shane.

[Justin Goeres]

QUOTE (Eugen Graf @ Jun 13 2008, 04:08 PM)

Why to use static dipatch member VI? It has only disadvantages to the dynamic dispatch member VI. Do it have less overhead for LV?

I asked AQ this question at NIWeek a couple of years ago when LV82 came out. I don't remember the exact answer. I know there is a small but real (~5us?) cost to the dynamic dispatch, but it seems to me that the bigger reason is just one of coding convention. If you're debugging code where all the method calls are dynamic dispatch, then you will always be uncertain about whether a particular call is dispatching to the class member VI you think it's dispatching to. There's a real mental cost to that uncertainty, and it will make your code harder to understand.

Using dynamic dispatch for everything can also introduce bugs into your code:

• If you have static dispatch method Parent.lvclass:MyMethod.vi and accidentally create another method with a colliding name in a child class (Child.lvclass:MyMethod.vi) your Run arrow will break.
  
• However, if you had MyMethod.vi set up as dynamic dispatch (because you decided to do everything that way), you wouldn't get any error from LabVIEW -- it would just happily start dynamically dispatching in places where you never intended it to do so.
  

I mention this because I've accidentally done exactly this before, and the name collision saved me because I was using static dispatch.

[Eugen Graf]

Thank you. So if I have NO inheritance in my LVOOP project, than it's always better to use static dispatch.

I should use dynamic dispatch first if I have some child classes ?

[Tomi Maila]

Static dispatching should be used

1. for the initialization method of a class
   
2. for high performance quickly executing methods executed more than ~ 100 000 times
   
3. for methods you do not want to allow to be overridden
   
4. for private methods
   
5. for methods that do not contain class input terminal
   
6. for methods you want to put inside polymorphic VI
   

Dynamics dispatching should be used

1. for cleanup method of a class
   
2. for recursively called methods (even for recursive init contrary to what was said above)
   
3. for all methods you want to allow child class to override
   
4. for all methods you are unsure if child class could benefit from overriding the method
   

Notice that you do not necessarily need to use dynamic dispatch output in dynamic dispatch methods. You can have dynamic dispatch input and a static dispatch output and a dynamic dispatch input wihtout any class type output. Normally you should use dynamic dispatch input together with dynamic dispatch output though. Use static dispatch output with dynamic dispatch input if you want a child class to return possibly other class type. See Aristos Queue's LVOOP Map as an example of this kind of metethods. Use dynamic dispatch input without class output if you want to clean up an object and the object is no longer valid after the method is executed.

[Aristos Queue]

QUOTE (Eugen Graf @ Jun 14 2008, 07:51 AM)

Thank you. So if I have NO inheritance in my LVOOP project, than it's always better to use static dispatch.

I should use dynamic dispatch first if I have some child classes ?

You should use static dispatch when it fits your design. You should use dynamic dispatch when it fits your design. I know... that isn't the simple rule that you're hoping for, but Tomi really did lay it out for you very very well.

If you have a class that you know will never have any descendants, then, yes, you should make everything static dispatch. There is a small performance overhead for dynamic dispatching and there's no point in paying it. The only exception to this would be a member VI that you want to call recursively since recursion in LV8.2 and 8.5 (and, I'll go ahead and say, for the forseeable future) requires a reentrant dynamic dispatch VI.

If your class has descendants, or if you expect it to have descendants in the future, or you can imagine a scenario in which someone might want to create descendants in the future, then you actually have to think about which to use. If you want to guarantee the behavior of a given subVI call is always the same -- meaning you want to make it one of the invariants of this class hierarchy -- then you should make it a static dispatch VI. Obviously, any member VI that does not take the class as an input is a static dispatch VI.

If you want to define an interface and let the child classes provide the details, then you want to create a dynamic dispatch member VI.

It is particularly common for certain algorthims to have a public static dispatch VI and a protected dynamic dispatch VI as its core. The static dispatch VI has certain pre-condition/post-condition work, and then the details at the core of the algorithm are filled in by the child classes. This is done to make sure that the child classes never break the contract of the pre-conditions/post-conditions. Since a child class doesn't have to use Call Parent Node when it overrides the parent, this is a useful technique (particularly on large programming teams) for making sure that all child classes are written to conform to certain rules while still giving them flexibility.