This is an update to an earlier edition of this page which spoke of virtualization instead of synthesis and was otherwise misleading. Here I speak of making a synthetic version of some particular small object within a platform; virtualization typically refers to a transformation on an entire platform. Sometimes I use counterfeit in place of “synthetic” without implying a technical distinction.
I have noticed some variations in goals for synthetic objects. Some advocate unlimited counterfeiting whereby any program P is able, for any capability B that it holds, to form a new ‘counterfeit’ capability S that can be used in any way that B could be used if only P implements S to behave sufficiently like B. A trivial example would be to maintain a count of invocations but otherwise pass the invocations messages on S thru to B unaltered. The platform design issue is whether to support counterfeiting, or support detection of counterfeit capabilities. Certainly there are many legitimate problems may be solved with synthetic or counterfeit versions of other capabilities.
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 synthesis 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 synthesis is incompatible with another pattern of capability parameters relying on synergy that seems not to have been generally described, despite being heavily used.
Note relation to inheritance by delegation. Synthetic is a relationship. One capability is a synthetic version of another, or is a counterfeit of another. address counterfeiting primitive keys.
The annalist will have to do for just now.