Thoughts on Class Data default values

[blawson]

I've been tangling a little with some classes designed for data serialization and also with just trying to serialize some classes.

One of the things I'm not wild about is the way that default values in a natively serialized object (using the binary or native XML tools) are omitted from the data. I feel like this breaks one of the goals of serializing the data, which is to separate the serialized data from the implementation of the object.

I'm considering making it a convention to try to use default values in class private data that are null or otherwise illegal (in context).

For new objects, this would require writing a constructor that sets the intended defaults.

For deserialized objects, this would require writing a method to validate an object against a class invariant. I'll claim this is a good habit.

Does anyone do it like this? Any drawbacks I'm missing? Any comments or ideas are appreciated.

Thanks,

-B

Edited March 8, 2011 by blawson

[Jon Kokott]

I've been tangling a little with some classes designed for data serialization and also with just trying to serialize some classes.

One of the things I'm not wild about is the way that default values in a natively serialized object (using the binary or native XML tools) are omitted from the data. I feel like this breaks one of the goals of serializing the data, which is to separate the serialized data from the implementation of the object.

I'm considering making it a convention to try to use default values in class private data that are null or otherwise illegal (in context).

For new objects, this would require writing a constructor that sets the intended defaults.

For deserialized objects, this would require writing a method to validate an object against a class invariant. I'll claim this is a good habit.

Does anyone do it like this? Any drawbacks I'm missing? Any comments or ideas are appreciated.

Thanks,

-B

When you say deserialized objects, are you talking about references to objects? (SEQ/DVR/LCOD or whatever implentation?)

in most implementations getting a reference to an object is a private operation anyway, what do you need to validate for?

[ned]

When you say deserialized objects, are you talking about references to objects? (SEQ/DVR/LCOD or whatever implentation?)

in most implementations getting a reference to an object is a private operation anyway, what do you need to validate for?

Serialization is converting a data structure to a form in which it can be saved or transmitted (a "flat" form like flattening data in LabVIEW). Nothing to do with references to objects.

[Daklu]

One of the things I'm not wild about is the way that default values in a natively serialized object are omitted from the data. I feel like this breaks one of the goals of serializing the data, which is to separate the serialized data from the implementation of the object.

To quote the teflon president, "I feel your pain."

This is one of those design decisions R&D had to make that doesn't have a clear "correct" solution. Consider what happens if you save an object to disk with default values, update the .ctl with new default values, and load the saved object? Should the loaded object contain the old default values or new default values? The answer is, it depends. NI had to choose something, so they implemented it so the object loads using the new default values.

I'm considering making it a convention to try to use default values in class private data that are null or otherwise illegal (in context).

Not all data types lend themselves to the default=null convention. Numbers are particularly problematic. Suppose you have a Sum class that adds two numbers and maintains the sum internally. When you load a Sum object from disk where sum=0, is that valid or not? Maybe it's the result of adding -3 and +3? If your serialized objects have data that could be "invalid," it's safer as a general practice to include a private "IsValid" flag.

[blawson]

To quote the teflon president, "I feel your pain."

This is one of those design decisions R&D had to make that doesn't have a clear "correct" solution. Consider what happens if you save an object to disk with default values, update the .ctl with new default values, and load the saved object? Should the loaded object contain the old default values or new default values? The answer is, it depends. NI had to choose something, so they implemented it so the object loads using the new default values.

Not all data types lend themselves to the default=null convention. Numbers are particularly problematic. Suppose you have a Sum class that adds two numbers and maintains the sum internally. When you load a Sum object from disk where sum=0, is that valid or not? Maybe it's the result of adding -3 and +3? If your serialized objects have data that could be "invalid," it's safer as a general practice to include a private "IsValid" flag.

Or in other words, a data type doesn't have an acceptable null if all possible values are acceptable. Booleans would be the easiest example.

I just want to find the middle ground where I can store the state of an object in a human friendly form without writing it out custom for every single class, and without it mysteriously changing if values are sometimes default and sometimes not.

Edited March 9, 2011 by blawson