Directory-based implementation.

We intend build a reasonably simple directory-based implementation of a model related to that of OKI.  That course model will be skeletonized directly into a directory structure. That skeleton can pretty much guide the faculty and TAs through what they need to do. If the faculty, TAs, and graders know what to put where, then not-so-friendly scripts can pick up whatever stuff we need, check that it's in the right format, and store it wherever and however we'd like.

• Atomic objects are represented via ordinary (text) files. Non-atomic objects are represented via directories with each member represented via a local file -- that file is a subdirectory when the member is non-atomic.
• Const objects are simple set to be read only.
• Classes are represented by skeleton directory heirarchies. To create an instance of a class simply do a recursive copy of the corresponding skeleton.
• Inheritance can be modeled by making (a copy of) the skeleton of the parent class a subdirectory of the child's skeleton and giving it a hidden (i.e., leading-dot) name. We must then install name-preserving symbolic links to the members of that subdirectory.
• By-reference members are represented/implemented via symbolic links. By-reference members are a good way to model many-to-one relationships.
• The identity id of a file-represented object is that file's pathname relative to the root of the Archive. Every object in the archive will have such a name. For directories that name will be unique, but ordinary files can have multiple pathnames. Avoiding the use of hard links insures that each file has a unique path that involves no symbolic links. Because they are used in symbolic links it is important that these names be stable -- we should avoid dangling symbolic links.
• The this pointer can then be represented as local directory, which can be represented via dot (i.e., `.') or via the return value of pwd.
• To get (the identity of) a member of an object simply append the component's name to the object's identity with a separating `/'.
• To delete an object simply use ``rm -R'' to remove it.
• To update an object simply mv to the object's identity (i.e., pathname) an object that holds the new value.
• A set is represented via a directory containing that set's members. To add an object to a set, simply mv it to the corresponding directory.
• A list of objects is represented by an in-memory list of the objects' identities (i.e., pathnames). Such lists can be persistently stored as a text files having one pathname per line. To list the members of a set, use glob and or a wildcard appended to the pathname of the set.
• The types of objects can be represented via the magic-number field in the file's i-node; in that case, create muse set the magic number when it copies a skeleton. Alternatively, we can treat Type as a by-reference member.
• Methods can be implemented as symbolic links to executables and/or scripts that have leading-dot names and whose read, write, and execute permissions are suitably restricted. In this case, we are treating methods as by-reference members.