I think what I’d like is, somewhere at the very root of an OOP object system, there to be two non-overrideable methods
- fromContext.toTransportFormat(Object, toContext) → Message
- toContext.fromTransportFormat(Message, fromContext) → Object
Where the “contexts” are the root of the object tree/soup that you’re exporting the object to or importing it from (so that the transport format knows which sub-objects it needs to link to or recreate), and include all the authentication credentials to prove that you have rights to read/create objects there.
Doesn’t matter what exactly the “transport format” is as long as a) standardised in the language definition as non-optional to implement, b) it’s machine-parseable and writeable at runtime by other objects - preferably in as close to whatever its “native syntax” or data format is, and c) the result of running fromTransportFormat on toTransportFormat is an object tree with the same semantics across systems.
While I’m at it, I think I want something like “Context” to also be an object which is a (transparent) container and proxy for other objects. So it can represent things like changesets, revisions, backups, volumes, etc, as a way out of the “one giant image” problem. It could also maybe contain side effects: tell the context to execute your messages such that they don’t mutate objects but instead generate a new context containing the changeset.
We do exactly this sort of thing in the “Containers” world, and so a general approach to “Containers for Objects” seems like it would be super useful. And it might also turn out to be “Firewalls for Objects” as well.
Of course, saying I want this doesn’t mean I want to build it, but at least knowing what I want is maybe 0.00001% of the battle.