LabVIEW
By-reference LabVOOP
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[i] and built-in reference types from [i]/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.
Message cross-posted to LAVA forums.
Tomi Maila
University of Helsinki
Research Scientist
Bio-IT
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[i] and built-in reference types from [i]/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.
Message cross-posted to LAVA forums.
Tomi Maila
University of Helsinki
Research Scientist
Bio-IT
Message Edited by Tomi M on 12-13-2006 03:47 PM
