Object serialization

[nbenn]

One way of looking at this is that we have two possibilities:

• serialize the entire object,
• include only the minimal necessary information.

Pros/Cons:

• If we attempt the serialize the entire object, we have tight coupling between serialized objects and the code base. Ensuring compatibility between an object serialized with a previous version of blockr with a newer version might become challenging.
• Partial serialization solves the issue of hard (impossible)-to-serialize objects such as environments at the cost of introducing a dependency between a serialized object and some form of a corresponding constructor
  • For package-based constructors, we can include the package name (and constructor name?) in the serialized object. Needs some form of reflection to infer the constructor name or we introduce a requirement that the constructor follows a certain naming scheme.
  • Precludes objects that are defined "on the fly"
• Complete serialization is easier to implement in the sense that we not have to distinguish between what is needed an what can be re-computed but needs special handling of objects like functions and environments
• For complete serialization a text-based format such a JSON introduces need for handling objects that do not have a natural string representation and probably a "native" format such a rds would be a better fit.

[DivadNojnarg]

In my opinion, CONS 1 is the reason why we should not serialise the entire object at all. I don't think we can totally remove dependencies but the lesser the better if we want to leave us enough space to evolve the code base in the future without bothering end users. Perhaps (a little) more "work" but for a better future.