The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
cs.cmu.edu

I'd almost forgotten this trick, just google cache:http://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf

request: could HN do this automatically pls? (similar to how it used to provide a second link to scribd for pdf) I always prefer a html version, to assess it. If it's interesting, and diagrams/formulae are garbled, I can always get the pdf later.

The distinction the author uses is that objects can have different implementations, but ADTs can't.

From this follows a streams of motherhoods of the advantages of having different implementations.

Curiously, from my scan, he doesn't seem to mention evolution of interfaces. That is, instead of evolution being just a different implementation of an identical interface, it is much more common for something to be added: extra data, extra services, extra features. The typical approach is to leave everything the same (so that old clients still work with this new API), and strcitly only add new methods (and/or types with superset values).

My reasonably involved studies of the evolution of Java classes in the standard packages for the purposes of serialization (which must store and recreate them), showed me that in practice, it's pretty rare for an implementation to change without the interface also changing. That is, I'm claiming:

  Interface evolution is more common than implementation evolution alone.

This higher frequency of interface evolution may be a reflection that we get paid for features, not refactoring.

Google cache is not scribd; it's plain html and not heavy javascript. I only referenced scribd as an additional link automatically added that had been done before, so it's not a biggie implementation-wise (maybe the old code is even still there), although I wouldn't expect it to be difficult anyway.

There wouldn't even need to be a check for if google had cached it yet - if nothing there, no harm done; and if popular, it quickly will be cached.

Data abstraction is an interesting topic in a language that doesn't really have data structures. ADTs are usually used to describe the allowable operations on either a data structure or some side-effectful system.

For describing data models, we have tables and (soon) integrity constraints. An integrity constraint is a rule which aborts the transaction if it produces any output. Simple integrity constraints like column types and foreign keys can potentially be removed when the compiler can prove that they will not be violated.

For derived data, rather than providing a method which returns the desired information, we define a view on the data eg instead of a getTotalSalary method we would define a rule that inserts data into the totalSalary table which is then either lazily evaluated on query or materialised and incrementally updated.

For modifying data we currently have no alternatives to directly working on the base data. There is some amount of work on bidirectional relational views but it seems like it adds a large amount of complexity for a problem we don't currently have.

We do intend to make scalar values and functions extensible, similar to http://www.postgresql.org/docs/8.3/static/xtypes.html

For side effects, we request actions by adding a row to a table that has a watcher attached. The interface is described by the set of tables available eg

    jobs started (id, input data...)
    jobs to be cancelled (id)
    jobs completed (id, output data...)

In any case, for most protocols you need to constrain not just the types of individual messages but the allowable sequences. ADTs don't help here. Where the protocol can be described by a state machine we can simply encode that state machine in a table and have a rule that verifies message histories and provides a list of currently allowable actions.