One of the most fundamental and general principles of design.
Let's say you have some entities (eg, objects, references) and you have some attributes of those entities (eg, security, versioning, persistence) which are
pervasive (entities with those attributes breed like maggots) and
orthogonal (there isn't any entity that could
not have those attributes by virtue of being that entity). So what do you do in that case? You build in the attributes into the definition of the entities.
This is as opposed to building the attributes
on top of the entities.
Examples
Let's say you've got an object graph. Every reference in that object graph
could be a capability (it's orthogonal) and every reference in that object graph
should be a capability (it's pervasive). Therefore, build capabilities into the object graph.
Let's say you've got a capability object graph. Every capability in that graph
could have the set of standard
PermissionFlags (since the standard permission flags are defined solely with respect to the object graph itself) and every capability
should have a set of permission flags. Therefore, build permission flags right into capabilities. See
BuildSecurityAbstractionsIntoCapabilities for more.
The same with versioning. The same with
GarbageCollection.
OrthogonalPersistence. It's not every process / object graph that should be persistent. In fact, if you make the memory manager orthogonally persistent, you create a
StrangeLoop in the OS. It's only typical user processes that should be orthogonally persistent. As a consequence, OP shouldn't be built into processes, but it should be built into user processes. (Which turns out to be trivial if you define processes in a sufficiently flexible manner.)
Non-examples
Changesets. Every object in an OS can belong to one or more changesets, but it's not the case that every object
is a changeset.
Execution. It's not every object that can accept a thread.
Process ports. It's not every process that
should have access to arbitrary other ports.