Dr. Damien's Development - Object Based File I/O V - Design III

[DFGray]

This week, finish the top–level design and specify the Data.type and Location.path strings.

Top Level Design

The primary change to the top–level design is implementation of Felix’ suggestions and addition of more properties and methods. The hierarchy has not changed. Note, however, that Data objects can now contain Data objects. This solves the container and Data.type issue by giving Data the option of being a container. Any given Data object will be a simple data type, but it may contain other Data objects.

File Class Hierarchy

I have added an archive file type to the class hierarchy, but other things are unchanged.

Location.path format

The file location is complicated by the fact that different file types have different capabilities. For example, INI file tags can be fully specified by a simple two–level path with the tag the final element and the group the first element (e.g. /MyGroup/MyTag). XML files, on the other hand, have two types of data — data contained between tags (e.g. <MyTag>MyData</MyTag>) and data contained in tag attributes (e.g.<MyTag MyData="data">). To further complicate things, XML can have multiple instances of the same tag with different data. However, since this is the XML version of an array, this case will be handled with the DataArray object with the path terminating with the name of the tag which repeats. The path format will thus have only two special characters.

The forward slash, “/”, will be used to separate elements in the path. A single forward slash denotes the root of the file. Paths which start with a forward slash are referenced from the root. Paths which start with anything else are referenced from the current file location.

The at sign, “@”, will be used to denote an alternate way to access data. For example, in XML files, this will extract tag attributes. File formats which do not need an alternate data access method may wish to implement it to maintain compatibility with those which do. For example, an HDF5 implementation my use the alternate read to signal reading an attribute, although the native HDF5 API uses the same method to specify atttributes and datasets.

Data.type format

The type format will be a simple string corresponding to the strings in <vi.lib>/Utility/VariantDataType/Type.ctl. Containers, such as arrays and clusters, as part of their class attributes, will contain an array of the contained Data classes. Types outside the realm of LabVIEW data types will also be added. For the moment, this will be limited to “File” to support archive files.

This should be enough design to start coding. Next time, I will start writing the top–level, abstract classes. If I have enough time, I will start a vertical slice through the binary file type.

Previous Posts In This Series:

1. Representative File Types with conversation on design
2. Requirements
3. Top Level Design
4. Design II

[tst]

---

@DFGray wrote:

...Data objects can now contain Data objects. This solves the container and Data.type issue by giving Data the option of being a container. Any given Data object will be a simple data type, but it may contain other Data objects. 

---

LVOOP does not allow recursive types. You can solve this by making the internal data item a LabVIEW Object and casting it down to to Data at run-time, but this opens room for run-time errors, which may require additional error handling.

[DFGray]

In reality, the Data objects will contain an instance of their parent, the top-level Data object.  The top level Data object is abstract and will not be used.  I am assured by R&D that this will work. I will agree that the top level Data object probably cannot have an array of Data objects.

I should probably make this explicit by moving the array of Data objects down into the DataScalar and DataArray objects.

[F._Schubert]

I don't see a problem with the recursive implementation. While the private data cluster can only contain the parent class, the accessors can contain the more specific type as control/indicator. As long as you adhere to a good coding standard of using the accessors only to get/set the property (also in the class methods, where you can access the private data cluster), this is safe.

The only issue with an array of classes is, that the type casting must be done by the class user (there are no 'generics' in LVOOP, PRC isn't working on arrays and there is no dynamic dispatching terminal for arrays of objects).

Felix

[DFGray]

The next installment, the first part of implementation, can be found here.