OpenG Variant to Config Suggestion

[tanksalm]

I've been using the OpenG Variant to Config VI to save clusters. It is a very nice function, but there are two issues which prevent it from being as useful as it could be. The first is that if I have a cluster with two identically-named items (stupid to do, but for argument's sake), one of the two values will not be saved. This is because the key in the key-value pair is the same in both cases, and so the second value with name "Variable" overwrites the first.

The second, closely related, is that if I have a nameless field in a cluster, this will go unsaved entirely (and will, in fact, throw an error, which is at least useful).

I realize that these are perfectly reasonable behaviors for the function, but would it not be possible to append a unique number to the end of each field's name (perhaps with some delimiter, like "variable_name - Number"), so you don't run into more uniqueness issues? This would fix both problems. As this would make the config file a little less readable, you could have a boolean input to the function which specifies whether or not to "force variable name uniqueness."

[asbo]

RE, the first: So what behavior are you expecting? I consider clusters with named elements to be a scoped namespace and a proper namespace shouldn't allow duplicate variable names (I don't know of any programming languages which allow variable overloading - loosely typed languages can be used for this in a roundabout way, though). I don't think this is an uncommon perspective on clusters.

RE, the second: This strikes me as a niche case, and my reasoning against the value of adding this functionality is more or less in line with my first response. From personal experience, these VIs get used most often when human-readable files are either desirable or necessary. It seems counter-intuitive to introduce features contrary to that. Why would you want anyone to have to figure the difference between Boolean1, Boolean2, and Boolean3? In what scenarios would you not have the ability to name these elements at development time?

[tanksalm]

I think I should clarify my situation and my suggestion.

I am inheriting code with at least a hundred settings, mostly stored in clusters. These settings are saved in between runs of the program, so the user can start back where he exited the program. These settings are currently put into a giant cluster and passed into a manually-coded vi (call it MasterStore.vi), where the cluster is manually disassembled, and each setting is manually saved into an xml file. So they have a hundred calls to the "Store to <xml> File" vi (I forget what it's called) and another hundred calls to the "Retrieve from <xml> File" vi. In order to save another variable, they (now I) must modify MasterSave and MasterRetrieve accordingly. A very convenient replacement for this would be the "Variant to Config" vi. It would be possible to ensure all of those names exist and are unique, but really, would you want that task? It more or less requires a program in itself to do. I wholeheartedly agree that human-readability is important - what I'm suggesting doesn't change that; it just prevents accidental information loss. The vi (in my mind) is as much about human-readability as it is about developer convenience.

The ideal behavior (in my opinion) would be for the vi to append a unique number to the end of duplicated variable names, and automatically name unnamed fields within the cluster. It's unnecessary to add a unique number to the end of all variables - I only suggested that for simplicity on the side of developing OpenG. Ideally (in my opinion), you could wire any cluster whatsoever to the vi, then read those same contents out of a file and back into the cluster next runtime. For instance, if I had the following cluster (four elements) that I feed into the vi:

Cluster_Name

String_Name = "Hello World"

Boolean_Name = True

Boolean_Name = False

[unnamed] = True

Then the save file would look like this:

[Cluster_Name]

String_Name = "Hello World"

Boolean_Name-1 = "TRUE"

Boolean_Name-2 = "FALSE"

Unnamed_Variable-1 = "TRUE"

Whereas currently, it looks like:

[Cluster_Name]

String_Name = "Hello World"

Boolean_Name = "FALSE" <--- Or maybe this is "TRUE".

The current functionality entails loss of information. I realize that the developer always has the ability to rename the elements. However, as "Variant to Config.vi" was also created for developer convenience, I think that my suggestion would be a very useful addition.

Edited September 14, 2011 by tanksalm

[Ed Dickens]

I agree that clusters should not have duplicate or unnamed elements.

I'd be more inclined to say the VI should check for duplicate names and throw an error if it finds any.

Losing data is something we certainly want to avoid.

[Ton Plomp]

Yes, I think the code should check for duplicate names and throw an error.

Additionally we could an 'auto-generate' option (default=false) that implies the suggestion by tanksalm and then throws a warning.

Ton

[jgcode]

I've been using the OpenG Variant to Config VI to save clusters. It is a very nice function, but there are two issues which prevent it from being as useful as it could be. The first is that if I have a cluster with two identically-named items (stupid to do, but for argument's sake), one of the two values will not be saved. This is because the key in the key-value pair is the same in both cases, and so the second value with name "Variable" overwrites the first.

Doesn't having identically named values in a cluster cause you issues when developing?

Anyways, IMHO identical items should not be used.

One problem I can see with this is that INI files are designed so that order of the sections/keys in the file does not matter (hence the name-value paradigm).

E.g. If in the future, the first item was removed from your cluster, then on reading an existing config file, the API would now return the first item's value when reading the original second item, and therefore introduce a bug into your code.

[Ed Dickens]

Doesn't having identically named values in a cluster cause you issues when developing?

Anyways, IMHO identical items should not be used.

One problem I can see with this is that INI files are designed so that order of the sections/keys in the file does not matter (hence the name-value paradigm).

E.g. If in the future, the first item was removed from your cluster, then on reading an existing config file, the API would now return the first item's value when reading the original second item, and therefore introduce a bug into your code.

Plus, if your cluster had the following:

String_Name = "Hello World"

Boolean_Name = True

[unnamed] = False

[unnamed] = True

The INI file would get written as:

[Cluster_Name]

String_Name = "Hello World"

Boolean_Name-1 = "TRUE"

Unnamed_Variable-1 = "FALSE"

Unnamed_Variable-2 = "TRUE"

When reading this back in, we would have to assume that "Unnamed_Variable-1" is linked to "Cluster Element 2" and "Unnamed_Variable-2" is linked to "Cluster Element 3". Again this could possibly introduce a bug in your application.

[jgcode]

When reading this back in, we would have to assume that "Unnamed_Variable-1" is linked to "Cluster Element 2" and "Unnamed_Variable-2" is linked to "Cluster Element 3". Again this could possibly introduce a bug in your application.

Yer, at the moment I can only see negative connotations with introducing such a change.

I really think it is on the user to define unique names when using this API.

FWIW, section names can be specified using the API, so even if two clusters that the same name you can override this (that's how I like to do it personally).

[jgcode]

Does anyone else have anything else to add - differing opinions etc...?

Or can I close this issue off?

[Val Brown]

This is an example , IMHO, of a unique situation that entails a purely local solution - what I would call a pipeline filter from my Unix days. The OP's original suggestions should definitely NOT be included in OpenG, but the idea of throwing an error on this condition should be.