Closing a file hierarchy

[LAVA 1.0 Content]

I keep talking to myself as it seem nobody takes part in to these discussions I try to initiate.

Consider the following problem. You have an object that needs closing, because it may contain a reference to a file or something similar. So how do you deal with it? LabVOOP doesn't have destructors and if I have understood correctly LabVOOP will not have destructors for classes anytime soon if ever. So you have to write your own destruction method that takes care of object cleanup.

How to implement such a destruction method. In order to cleanup the object to the following.

• Close all resources such as files and database connections etc
  
• Close all private member objects
  
• Call parent class destructor
  

Your destructor needs to be dynamic VI so that the correct destructor gets called for each object. So your destructor first cleans up all the non-object stuff such as closes files that has been opened. Then it needs to call destructor for all member objects if they have destructor. In general member objects of course do have destructor so these need to be called. Last a "call parent method node needs to be called so that also parent class objects get correctly cleaned up. So this is a general procedure that applies to any class that may need cleanup.

As your destructor needs to be dynamic VI, it cannot be reentrant and even if it could recursive calls cannot be made in LabVIEW. So you may easily run in trouble when cleaning stuff up if your object hierarchy has recursive data structures.

Consider for example that you object that refers to a file system object (my standard example). It has subclasses file and folder. As files and folders have a operating system handle, this handle needs to be closed for each opened file and folder. So you need to have a destructor for you file system object class and it's decendent classes file class and folder class.

Consider now that you have an open folder which has another folder inside it and this folder has a file inside it. So the directory structure looks the following:

• C:\
  • Data
    • MyFile.txt
      

You try to use LabVOOP to encapsulate such a structure. So you use the following class hierarchy to represent file system.

• File System Object
  • Folder (Array[File System Object])
    
  • File
    

Where expression (Array[File System Object]) means that Folder refers to zero or more subobjects of class File System Object.

File System object has a Dynamic VI "Close.vi" to handle cleanup. File and Folder classes both have an override VI "Close.vi" overriding parent method.

So what happens when we call Close.vi for the object "C:\". It needs to clean up it's member objects. So how to do this? Call close for each member objects. So in order to cleanup properly Folder class object "C:\" needs to call close for Folder class object "Data". This however is not possible as the call would be recursive. Nasty, isn't it?

I'm facing this very problem of closing a file hierarchy. How to implement it properly? I have no idea of any good solution.

I think LabVIEW 8.0 without recursive calls was managable. LabVOOP without recursive calls to dynamic VIs is fatally handicapped as stack based recursion cannot be used since the whole class hierarchy is not know in general during the development time of the root class. Therefore the developer of the root class cannot know what kind of stack recursion algorith he should use to take care of all possible uses of the class.

[Kurt Friday]

Hi Jimi

I'm currently working on a GOOP framework that merges the existing Open Source GOOP Template and LVOOP to provide a by ref implementation. You have no doubt seen the code I posted.

Merging-LVOOP-and-the-Open-Source-GOOP-Template

If you are interested in dynamic destructors then the current model implements them, take a look at the plugin demo, although I haven't placed any cleanup code in the child destructors you can see how it would be done.

[LAVA 1.0 Content]

If you are interested in dynamic destructors then the current model implements them, take a look at the plugin demo, although I haven't placed any cleanup code in the child destructors you can see how it would be done.

Can the destructors be called recursively? High-performance recursion is what I need, reentrancy without recursion is useless for this use case.

[Kurt Friday]

I havent tested that yet, I'll get back to you on that.