One issue of deserialization that Java tackles is ensuring that objects remain singletons. Consider this poor example:

const final class Credentials {
  static const Credentials SYSTEM := Credentials.internalMake("System")
  const Str name

  static Credentials make(Str name := null) {
    if (name == "System") return SYSTEM
    return internalMake(name)
  }
  private static new Credentials internalMake(Str name) {
    this.name = name
  }
}

Unless I'm mistaken, when deserialized, this class will not protect the singleton status of SYSTEM. Most (all?) of the constructor proposals also do not handle this case. In other words, there is a requirement to force deserialization to go via a factory.

Java tackles this using a hack - private Object readReplace(Object).

I'd like to propose that Fan needs a static factory fromStream method, like :

static Point fromStream(Point point) {
  // vaildate (depend on the outcome of the constructor discussions)
  // possibly return cached value
}

This would be called by deserialization after constructing an object. The returned object is used in place of the object passed in by the deserialization.

The astute amongst you may notice that a related (the same?) problem afflicts construction via construction-with-blocks....

I thought that the deserialization code used Type.make which just invokes your make method (be it constructor or static). But I'll have to look at it.

But I agree we need to have a clear process for pre-processing and post-processing for deserialization (it is very much like constructors).