[feature] Storable doesn't support classes

[tonycoz]

Per subject.

There's a couple of issues I can see in implementing it.

non-hooked

If we freeze an object it's going to be very sensitive to the class definition, unlike a typical hash-based object.

If the user inserts a new field or re-orders the fields and we've just frozen each of the member variables in order the values will end up in different member variables on thaw.

hooked

One design problem with STORABLE_thaw is it pre-creates the hash/array object that's passed to STORABLE_thaw and doesn't allow it to be replaced.

This means Storable would need to be able to create a blank object of class to pass to STORABLE_thaw.

I've considered adding an alternative to STORABLE_thaw that accepts a returned object, but this has problems with object tag ordering (the mechanism used to ensure multiple references to the same object thaw to references to the same object).

[leonerd]

Yeah it's all messy however you do it.

In particular with respect to field ordering, it gets even worse when you consider the "naked" representation of non-scalar fields.

Store one of these:

class TrickyContainers {
   field @arr; field %hash;
}

and you'll write a plain AV and an HV into the stored representation. Now swap the order of the fields and load it again. Without at least a bit of sanity-checking you'll attempt to stuff an HV into an array variable, and an AV into a hash one.

Even with sanity checking at that level, there's nothing to tell you you've messed up the assignments into two e.g. scalar fields.

Should the Storable representation involve the names of the fields, by way of at least some amount of sanity-check? Perhaps so.

More design discussion needed.