Orthogonal Versioning

OrthogonalVersioning means you don't have to "backup" and "recover" files, the OperatingSystem 'just' keeps versions of all objects, when they are modified.

If you implement OrthogonalPersistence using a LoggingFileSystem, you get orthogonal versioning for free, but at a global level only. Fine-grained versioning is a completely different matter.

---

That is just the point suggested in GarbageCollectionUnderVersioning (I guess). For fine-grained versioning we need support by the object system, otherwise garbage collecting becomes essentially undoable.

The question is, how to do the versioning. I think, that the idea suggested on GarbageCollectionUnderVersioning was along the following lines:

• Take a functional approach: All objects behave immutably (though a smart compiler might replace many changes with in-place updates).
• Each object has a versioning policy attached to it (probably the default should be not to version in which case all related code may be optimized away).
• This versioning policy is used by the garbage collector to discard matching versions (old ones).
• Each object can be querried for its previous versions.

In fact, the default should be to keep old versions forever.

"immutable"? Objects in an OBJECT ORIENTED system don't behave immutably by any stretch of the imagination. In fact, why anyone would assume ReferentialTransparency when OBJECTS are mentioned is simply beyond me.

[What about immutable objects is not immutable? Isn't that the idea? If you don't understand immutable object types, you may want to read a little before going on a rant.]

And finally, each object cannot be queried for its previous versions. Nor are versioning policies attached to objects. Both are attached to REFERENCES. That's the sane way to do it since it means that two different users may have access to different versions of an object, and that they can each specify how long they want those versions around. Objects maintain themselves, and references maintain all ACCESS to objects. Anyone who knows about capabilities should understand that.

[You seem to be going on some crazy rant here, about a particular definition of the word 'object'. You are the first on this page to bring up capabilities. Get a grip.]

The open questions with this approach are:

• What to do if the object tree spans multiple processes or is distributed (functional languages, that support concurrency should have an answer to this).
• How to integrate persistence.

You don't integrate persistence. It isn't even meaningful to "integrate persistence" into the object graph. Is RAM supposed to be persistent? Is specially marked volatile RAM supposed to be persistent? Of course not, the notion is ludicrous. Persistence is provided by a specific component in an operating system, and orthogonal persistence is provided by having every process run from within that component.

[Well, now that you have handed the answer down from god himself, I guess there is no need for further discussion. (hint, this is another rant based on some obscure definition of 'integrate')]

Similarly, object GRAPHS that span multiple processes have absolutely nothing to do with concurrency. There's no a priori reason why a functional language that supports concurrency would have a solution to the decentralization of TheObjectGraph. And there's plenty of reason to believe they don't. For instance, the fact that FUNCTIONAL languages and OBJECT-ORIENTED concepts don't fit together that well.

[I'm fascinated by the assertion that FUNCTIONAL and OBJECT-ORIENTED concepts don't fit that well together. Maybe have a read of http://www.ccs.neu.edu/home/matthias/Presentations/ecoop2004.pdf]

[Wow, we are getting pretty deep here. So, if I understand you correctly, "multiple processes" has nothing to do with "concurrency". Did I get that right? Thanks for the clarification.]