serializing objects (object declarations)

[tombentley]

We need to be able to serialize the values of toplevel object declarations. We support true, false and null directly, but we need to support at least empty too (otherwise we can't serialize Tuples with empty tails).

The syntax isn't really a problem, something like this would do

{
 "$type": "ceylon.language::empty"
}

[tombentley]

I can now serialize tuples, but this isn't still isn't really fixed.

Suppose I try to serialize Singleton(smaller), I can generate some JSON like this:

[
 {
  "$": "0",
  "$type": "ceylon.language::Singleton<ceylon.language::Comparison>",
  "element@": -1
 },
 {
  "$": "-1",
  "$type": "ceylon.language::smaller"
 }
]

which makes sense, but when I deserialize that I encounter the top-level hash for smaller. The deserialization API forces me to get a Reference to it, because that's how the API works, but I can't because the API throws if I call context.reference(id, <class of smaller>), because smaller isn't serializable and so lacks a $deserialize$() method.

[tombentley]

I wonder if the deserialization API needs a way to obtain a Reference to something that isn't serializable on the understanding that the serialization library can deserialize it anyway. For example another way this could be useful is when a serializable instance has a reference to a meta model object (not serializable), but it's perfectly possible to serialize a reference to that thing and resolve/parse it during deserialization.

[tombentley]

I've been thinking over the pros and cons of how to support this object serialization problem. Solving it for objects themselves isn't particularly difficult so long as it's acceptable to special-case them within the serialization API. That basically involves

• not caring about their fields (i.e. they're leaves of the object graph) during serialization,
• not trying to instantiate them during deserialization, but rather looking them up via the metamodel, and
• not trying to invoke the hidden $deserialize$() method (because they don't have one).

Trying to generalize this to other things which can be given a meaningful representation in terms different from their instances runtime state is much harder. Specifically things like

• Class (can be persisted via a package-qualified type expression)
• Date and Datetime (the ISO formats)
• Uri (it's external form)

would benefit from this sort of thing. It's perverse to encounter a Date within an object graph and persist it as the fields of the Date class, especially when serializing to a format like JSON which is vaguely human-readable.

The problem is we want to maintain the property that the API exposes no one to uninitialized objects. There are several cases where we need to use the (unitialized) object while deserializing another object, but for these "parse a well-known format" classes we can't have an instance until we've parsed the data, and we can only do that once we know what the Deconstructed is, but that happens in the call to DeserializableReference.deserialize() which after we may need the instance to be available.