Copying

When a container object has been edited, but some of its component objects have not been changed, it is desirable to be able to copy the component object, or a reference to it, without first restoring that object into memory and then storing it back again. There are many motivations for this:

• space requirement: in most contexts, both the external representation of the component object (in a file) and its internal representation use RAM space. Restoring an object from a file generates a second instance of it; storing it back into another file generates a third instance, before the first file and the internal representation can be deleted. This triplication of space requirement is especially undesirable for large objects.

• generality: it is desirable to be able to copy an object without knowing its detail, e.g. which program created it.

• security: if an object is password protected, it cannot be opened without specifying a password. It is undesirable to have to specify a password to copy an embedded object, especially if the only requirement is to edit that object's container.

There are two main cases:

• with a direct file store, the component object data must be copied from one store to another without internalizing it: this is achieved by copying the streams directly, and this itself is only possible because of embedded stores

• with a permanent file store, the component object can be left in place, and just its stream id re-used: this is achieved by copying the Swizzle, and is provided by store map functions