By-reference LabVOOP

[LAVA 1.0 Content]

Hi,

I've been supporting NI choice for by-value objects in LabVOOP. I thought that there could be a transformation from by-value objects into by-reference objects and back. Now that I've used LabVOOP very extensively for many months, I've come into a different conclusion. First current LVOOP cannot handle trees and graphs or any similar complicated data structures easily or effectively. I also now think that the by-value <--> by-refence transformation may make things messy and complicated and decrease the readability of the code. As a result I no longer support it as an alternative for native by-ref classes.

I've now a vision that both by-ref objects and by-value objects can coexist natively and we could still have backwards compatibility with LV version 8.20. Now all LV classes derive from LabVIEW Object class. This built-in class should be renamed into LabVIEW Value Object. Two new built-in classes LabVIEW Reference Object and LabVIEW Object should be added to a future release of LabVIEW. Both LabVIEW Value Object and LabVIEW Reference Object would derive from LabVIEW Object class. All by-value classes e.g. present LabVIEW classes would derive from LabVIEW Value Object class. All new by-reference objects would derive from new LabVIEW Reference Object class (see the attached image below).

This implementation would allow both by-value and by-reference objects coexist. Present LV classes would work properly in the new system. The system would be effective performance wise, as the developer could create by-value classes when they are the most appropriate choice. On the other hand the language would be more expressive as by-reference objects can more easily express more complex data structures and refer to real-world objects as well.

As an extension to this model, current built-in types could also be made classes. This would only mean that built-in value types would derive from LabVIEW Value Object and built-in reference types from /LabVIEW Reference Object. These classes representing built-in properties couldn't be override, would have no methods and the only way to access them would be using built-in operations and built-in controls as is the case currently. However having a class hierarchy for built-in types would allow writing more reusable and modular code easier. One could for example write a subVI that accepts all objects of type Numeric as inputs and returns an object of the same type.

Native by-reference objects are needed to provide better interoperability between Java Virtual Machine/.NET framework and LabVIEW. Now LV can call .NET object, but .NET or Java Objects cannot call LabVIEW. This is a problem as enterprise applications cannot easily be integrated with LabVIEW.

Message cross-posted to the dark side (NI forums).

Jimi a.k.a.

Tomi Maila

University of Helsinki

Research Scientist

Bio-IT

[Aristos Queue]

I didn't quite grasp the reasoning for LabVIEW Value Class.

Why can't the LabVIEW Reference Class inherit from the existing LabVIEW Object?

[LAVA 1.0 Content]

I didn't quite grasp the reasoning for LabVIEW Value Class.

Why can't the LabVIEW Reference Class inherit from the existing LabVIEW Object?

I think by-value objects and by-reference objects are logically different but of equal importance. Because of this logical difference, there is also a need to have a class hierachy difference between these two groups. As I have understood current LabVIEW Objects are all by-value objects. This has been explicitly stated in when LV 8.20 was released. This also means that there may already be many applications and libraries that rely on the fact that any object of class LabVIEW Object is a by-value object. So the meaning of current LabVIEW Object cannot be easily changed, the name however can be changed to correspond the meaning.

By-reference objects and by-value objects also behave differently. By-reference objects are not copied when wire is branched whereas by-value objects are copied. By-reference objects can be passed to Java and .NET methods (in the future) and by-value objects cannot. Later on NI development team may be adding methods that are specific to by-value objects and different methods that are specific to by-reference objects. If there wouldn't be separate LabVIEW Value Object and LabVIEW Reference Object classes, this wouldn't be possible. Consider you would like to have a method toReferenceObject as a member method of class LabVIEW Value Object. If LabVIEW Reference Object would derive directly from existing LabVIEW Object, this method would make no sense as there is not meanig of transforming a reference into a reference. A more detailed scetch of the class hierarchy is below.

[robijn]

First current LVOOP cannot handle trees and graphs or any similar complicated data structures easily or effectively. I also now think that the by-value <--> by-refence transformation may make things messy and complicated and decrease the readability of the code.

I have not actually heard of a single real-world application with objects yet. I think I know sufficient advanced engineers in the field.

I think by-value objects and by-reference objects are logically different but of equal importance.

Well, I think they exist for a different purpose. You need by-ref for objects to be useful, and you need by-value if you want to be able to put all traditional LV types in classes. By-value classes are not on all points an improvement over a cluster. Their data can not be visualized on a front panel like with a normal cluster. And that transparency has always been what made LabVIEW so powerful. Program some code, set some values on the FP, run the VI and see if it works. Rapid Development !

I've not really understood what basic LabVIEW objects NI would like to extend with the classes. I can imagine you want to have the existing Control's class structure converted to the LVOO class structure, so that you can "extend" controls yourself. However those would all need to be by-ref, not by-value, or you would not be able to refer to a control on the front panel. But would you actually want classes for setting properties of controls ? Or for some type of data ? Maybe Stephen can give us some examples of useful objects derived of traditional LV types..?

I like your root classes idea for its clarity and because it keeps things fundamentally sound. A distinctive difference in the looks of the wire and icon should also be possible.

Joris

[crelf]

I have not actually heard of a single real-world application with objects yet.

Really? You haven't heard of any applications written with OOP? I've written heaps of them!

[LAVA 1.0 Content]

Their data can not be visualized on a front panel like with a normal cluster. And that transparency has always been what made LabVIEW so powerful. Program some code, set some values on the FP, run the VI and see if it works. Rapid Development !

This is a good point. There should be some solution to this problem, some sort of debug mode.

I like your root classes idea for its clarity and because it keeps things fundamentally sound. A distinctive difference in the looks of the wire and icon should also be possible.

Thanks, I agree with you that wires should look different but only by default. You can make by-reference objects that act like by-value objects by overriding default copy-constructor of the class. In these cases you may want the wire to also look like by-value wire. Some sort of dashed line for reference objects would be perfect.

[robijn]

Really? You haven't heard of any applications written with OOP? I've written heaps of them!

I meant with the native objects obviously ! You did use those ?

Joris

[LAVA 1.0 Content]

As a side note, if LabVOOP later will support concept of interfaces similar to Java interfaces then the class hierarchy I proposed allow by-reference classes not only behave like by-value classes but these classes can also really implement "LabVIEW Value Object" interface.

[crelf]

I meant with the native objects obviously !

Well, obviously it wasn't obvious.