Open tombentley opened 9 years ago
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.
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.
I've been thinking over the pros and cons of how to support this object
serialization problem. Solving it for object
s themselves isn't particularly difficult so long as it's acceptable to special-case them within the serialization API. That basically involves
$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
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.
We need to be able to serialize the values of toplevel
object
declarations. We supporttrue
,false
andnull
directly, but we need to support at leastempty
too (otherwise we can't serializeTuple
s with empty tails).The syntax isn't really a problem, something like this would do