Norman Hardy; 2009 Feb 17
This question arose recently on a mailing list.
Sometimes it is possible to test an object subsequent to its creation to insure that it has some property that will, by its internal logic, persist.
Is there a capability pattern to do this?
Here is a Keykos implementation if you are attending to incentives to pay for the storage required to remember the results of a verification.
When R wants to deliver a p to S and convince S that the p has the properties vouched for by Q, he delivers a p boxed by Q.
This box can be passed along and each recipient is in a position to verify that the box came from Q who is trusted not to build such boxes unless the new property has been verified by Q.
Holders of such boxes invoke the Q factory in order to verify that it is a product of the Q factory.
R pays the cost of the box.
- P produces a factory that yields p’s.
- Q believes in some integrity properties of p’s.
- Q writes code that examines a p and produces a box in which the p is stored.
- Q delivers that code as a factory.
- When R wants a p vouched for by Q, he invokes Q’s factory to get a boxed version of some p.
- The box probably delivers its p unboxed upon request.
The behavior of a p must have a class of states with no transition arcs out of the class.
Q only verifies, or places, an instance p in the class.