I have noticed some variations in goals for vitrualization.
Some advocate full virtualizability whereby any program P is able, for any capability B that it holds, to form a new ‘virtual’ capability V that can be used in any way that B could be used if only P implements V to behave sufficiently like B.
An example would be to maintain a count of invocations but otherwise pass the invocations messages on V thru to B unaltered.
This is unlike what I call the wrapper pattern where the functionality of B is preserved but an adaptor is added to accommodate the nature of the invocations needed to attain that functionality.
A wrapped object cannot be substituted for its base capability for it is invoked with different logic.
The main purposes of this notion of virtualization is to make small changes to B suitable to the job at hand.
This is similar to some of the purposes for inheritance, especially inheritance by delegation.
This sort of virtualization is incompatible with another pattern of capability parameters relying on synergy that seems not to have been generally described, despite being heavily used.
Does Synergy Totally Break Virtualization?
Synergy is widely available to Keykos programs and is indeed essential to much of its security.
Yet many virtual constructs work perfectly well in Keykos even if full virtualizability is unachievable.
A different virtualizability is in use in Keykos.
I will give a few examples and then try to characterize the pattern.
The annalist will have to do for just now.
See a messy but serviceable scenario.