LAVA 1.0 Content Posted November 20, 2006 Report Share Posted November 20, 2006 Consider a LabVOOP object. It can contain provate data elements. These data elements can be objects or contain objects (e.g. in clusters and arrays) and these objects can further contain private data elements that are objects. Do not confuse term object with term class here. So the object refer to other objects which refer to other objects and so on. This construct forms a data structure we call a tree. As objects do not share memory in LabVOOP, there are no nodes (objects) in this tree that are children of more than a single other node. Furthermore objects cannot refer to themselves. The question now is how to effectively modify for example a leaf node of such a tree. As examples are easier to comprehend, let's make an example. Consider a file system. You start with the following object hierarchy. File System ObjectFile Folder File is a data container, it doesn't refer to any other file system object. However Folder refers to zero or more other File System Objects. This UML relation looks the following. Folder (1) ----------> (*) File System Object Let's consider that we now want to add a file to this file system hierarchy. Now we can call Add File method of a Folder, but as objects are by-value and not by-reference, this doesn't update the tree but creates a copy of the original Folder which is updated. The challenge now is what kind of design pattern should be used in general so that the whole tree gets update appropriately when it is passed to a method that modifies one of its nodes that is not a root node. An intuitive way would be to implement a dynamic method "Add to Tree" to the File System Object class. This call would add a file or folder to the tree to a position specified by user. The method would return a modified tree. Simple and elegant but in LabVIEW it doesn't work. First recursion is not possible. Second dynamic VIs cannot be reentrant so that recursion is not even possible using call by reference node. Third there is a bug that crashes LabVIEW and corrupts projects when adding a call by ref node to a class method. So this method seems to be opted out. Well, you can traverse the tree using shift register as a stacks. To be able to traverse the tree, we add a dynamic method Get Children to File System Object class. This method is overridden by File and Foder classes. This makes your simple method of adding a node quite complicated. It works for the File System Object case as all children objects are File System Objects. But this is not always the case. You may need to modify a tree where you do not know what kind of objects there are in the object tree. So currently I have no idea how to manage tree traversal in a general use case where you do not know what kind of objects there are in the tree. Recursion would be a reasonable way to go, but for some reason it is not possible in LabVIEW. I now challenge you dear developers to think of a general way to modify by-value object so that the modification doesn't target to the object itself but one of it's private data member objects or their private data member objects in such a way that the hierarchy may contain multiple instances of the same runtime class, e.g., a Folder. If there is not general solution to this problem or the solution is so complicated that it's practically unusable, then I strongly suggest NI to make recursive calls to both dynamic and static class methods possible. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.