We sometimes discover connections between two conceptual domains that had evolved separately. This is particularly true in mathematics but there are important instances in computer science as well. These connections (bridges here) allow transport of ideas from one domain to the other. I will discuss some here that have helped me produce new ideas.

I had the great pleasure of meeting Jacob Rabinow once. He rivals Edison in the number of useful inventions that he has made. He has also made a comfortable living from his inventions. He told me that a significant number of his inventions resulted in mapping other prior inventions across concept bridges (my term not his; I don’t recall his term) and making minor adjustments. A significant example was the magnetic clutch upon which he held the invention. A previous invention was an electric clutch which used electrostatic attraction to bring two clutch plates together. Rabinow knew how to map electrostatic attraction into magnetic attraction and he quickly produced the patent for the magnetic clutch. For about two decades every magnetic tape unit had two magnetic clutches, one for each real. The electrostatic clutch saw little use.

Here is a bridge between public key crypto and capabilities.

Actors; KeyKos Objects; OO Objects

I knew of Simula when we started Keykos in 1972 but had not studied it in detail. I new that Simula provided encapsulation like what we planned for Keykos. We viewed and still do, routine invocations as providing encapsulation for the variables on the stack. What I know of OO languages is limited mostly to C++, Java and a little SmallTalk.

Keykos objects were conceived as separate machines, almost. There were to be no allowed connections except as explicitly provided by capabilities which we called keys. We attempted to make miscellaneous keys appear as if they might really be implemented in user code where they were indeed implemented by privileged kernel code. As a result the kernel implemented objects were later conceptually unified under the emerging object paradigm.

The Actors papers were brought to my attention after the main Keykos architecture was finished. The main difference was that domains could be invoked multiple times. I now think of Actors as the unifying scheme except that Actors ignores resource issues whereas Keykos does not.

Bridge between OO and Keykos

In this section I will put Java terminology in this font and Keykos terminology like this. The boundaries between Keykos objects are very clear at least to me. Java’s object reference is the only thing in sight to play the role of capability. It is not initially clear which Java things should play the conceptual role of Object. Presumably an instance should be an object. The fact that instances have unfettered access to static variables means that siblings can communicate without means of object reference. I propose that the class object be seen as an object and each instance has an implicit capability to its class object.

Inheritance is a worse problem. I think that

Some notes on language design and its relevance to Capability discipline