Thursday, August 17, 2006

Dynamic Dispatching

Encapsulation and inheritance are good features, but the part of LabVOOP that I believe really takes the cake is dynamic dispatching.

Dynamic dispatching is, however, a little difficult to explain. Here goes...


Consider this diagram snippet. We have a wire of a certain datatype, carrying data of a certain datatype, passing that data into a subVI.

Before LabVIEW 8.2, you knew for certain that the data on the wire was the same type as the wire, and that the VI that opened when you double-clicked on the subVI was the one that would execute at run-time.

Both of these are no longer true.

A wire of a class datatype can carry data of that class or any class that inherits from it. So, using our previous example, a Link wire can carry a Link object, a Web link object, or a VI link object.

Dynamic dispatching gives you the ability to call a different subVI, depending on the datatype of the input data. It is run-time polymorphism.

I think this is easier to show with an example, so I'm going to provide one with my next post. Time to get those copies of LabVIEW 8.20 installed! :-)

Labels:

7 Comments:

Anonymous Anonymous said...

I am enjoying your posts on GOOP and I hope you can find the time to keep doing this. The way you are doing it with snippets is very helpful. I have read articles here and there on GOOP, such as those that were in LaBVIEW Technical Resource, and even had some hands-on instruction in the old LabVIEW Advanced I course that VI Engineering was involved in (I think it was the Endevo version of GOOP they worked with).

I don't know for sure if I well ever need to use GOOP but I want to at least learn it well enough to know when it would seem to be a good architecture option.

Using LabVIEW since 1993.

Sincerely,

Don

5:49 PM, August 19, 2006  
Blogger Christina said...

Thank you for reading! As you can probably tell, I'm pretty excited about the potential of LabVIEW Object-Oriented Programming, and I'm glad to have an opportunity to share it with you.

One thing I need to point out, though, is that LabVOOP is not GOOP. I want to do whatever I can to minimize the confusion between the two.

GOOP refers to the toolkit that's implemented entirely by VIs and uses a by-reference model for its objects. LabVIEW Object-Oriented Programming extends LabVIEW's programming language in ways that were previously not possible, including by-value objects.

GOOP continues to work in LabVIEW 8.20 and should continue to work for the foreseeable future. We're eventually going to publish a FAQ that elaborates on the differences between them, and why you might choose one over the other.

12:57 PM, August 21, 2006  
Anonymous Anonymous said...

Thanks for the clarification. I had not reviewed the GOOP documents recently, and I believed you were attempting to incorporate the same functionality as GOOP. I think the FAQ will be helpful to differentiate.

Sincerely,

Don

9:31 AM, August 22, 2006  
Anonymous Stephen Mercer (LVR&D) said...

Dear anonymous:
Just so you know, we're using the acronym LabVOOP to contrast with GOOP. It's easier to say than the whole, "LabVIEW Object-Oriented Programming." ;-)

5:40 PM, August 23, 2006  
Blogger Christina said...

The LabVIEW Object-Oriented Programming FAQ is now available on DevZone.

7:36 AM, August 31, 2006  
Anonymous Anonymous said...

Thanks for taking time to explain valuable LabVOOP concepts. I am still puzzled as what is the difference between polymorphic VI's in LabVIEW and polymorphic nature of Classes.

11:41 PM, September 17, 2006  
Blogger Christina said...

Polymorphic VIs are edit-time polymorphism. Based on the datatype of the wires going to the instance, LabVIEW changes the VI that will be called at run-time.

Dynamic dispatching is run-time polymorphism. Based on the datatype of the data, LabVIEW calls the appropriate VI at run-time.

It's important to realize that Classes introduce the ability for the data on a wire to have a different datatype than the wire itself. The data can be the same class or any descendant class. This is what makes run-time polymorphism possible.

10:58 AM, September 19, 2006  

Post a Comment

<< Home