Instances and Copies

Let's start with the simplest possible case, a single file. For present purposes it's best to imagine the file is of a kind that one creates but doesn't normally edit—an executable, say, or a Myth II plugin. I find it also helps to imagine the file being small. In any case, we have a single file.

Now suppose we make a backup copy of the file. Even with a backup, you wouldn't say you have two files, you'd say you have two copies of the same file. In other words, there is a single object, of which two copies exist.

Or suppose we make several copies … make several backups, store copies in compressed form, email encrypted copies to our friends, post it on our web server, load it into memory, or even write the binary content down by hand on a piece of paper. It's still clear that there's just a single object.

So far so good. Now suppose that we make just one more copy, but with the intent of creating a new object. Suppose, for example, that the file, originally a Myth II plugin, happens to be exactly the right size for use as an encryption key. That's a bit contrived, I admit, but it's the right idea, and it will make a lot more sense later on, in a context in which files can be edited. Anyway, we now have two distinct objects.

Of course, we can make copies of the new object, too … sending the encryption key to all our friends, and so on.

By now it should be clear that the number of copies of each object is not really of much interest, that the important thing is the number of objects.

In the rest of these essays, I will be using the filled-in dots almost exclusively; it will be up to you to remember that each such dot represents any number of identical copies.

Now that you have the idea, let me improve the terminology. First I should explain what I see as the problem, which is that the noun “copy” has two different meanings. In terms of objects, making a copy means creating a new object, but in terms of files, making a copy means creating a new open dot, regardless of whether or not that dot is part of the same object. Since I tend to think in terms of objects, I'll use “copy” to refer to objects, and use “instance” to refer to open dots. (So, to me, “backup copy” is an oxymoron.)

The verb “copy”, I think, has a single clear meaning, but we still need to be careful with it. Copying a file is a well-defined idea, but in terms of objects it's ambiguous—when one copies a file, one may be either copying or reinstantiating the associated object, depending on circumstances.

Using the new terminology, I can now tell you exactly what the different types of dot are for. An open dot represents a single instance, while a filled-in dot represents a set of identical instances, all belonging to the same object.

Finally, I ought to say something here about the words “object” and “instance”, about how my usage compares to the usage common in object-oriented programming (OOP). An object, in my terms, is an abstraction spanning files and even computers, while an instance is an object instance, i.e., an instance of a particular object. An OOP-object (see Hierarchical Language), on the other hand, is just an instance that happens to reside in memory, and an OOP-instance is just a synonym for an OOP-object, with reference to the fact that it's a class instance, i.e., an instance of a particular class. I was going to apologize for any confusion my usage might cause, but on reflection I decided not to, because the same confusion already exists within object-oriented terminology. During the design phase, one might talk about an object without regard to whether it exists in a database or in memory, or both, but during development one would still blithely talk about, say, a copy constructor making a copy of such an object. So I won't apologize; in fact, you should thank me for the clarification.