Once again, I have to apologise for a stupidly long and stupidly late
reply. I've tried to make this thing a little more digestible by
chopping it into three chunks. In order to keep any replies together,
I suggest that people reply to the third part unless the reply is very
specific to one of the other parts. This first part is (I hope)
relatively fun.
First of all: I'll refer to 'relation-directories' as
'link-directories' from now on; the new term should be more
enlightening and less misleading. (Sorry if the change causes any
temporary confusion.) Again, each link-directory expresses one
instance of a relation; in RDB terms that's one tuple of a relation or
one row of a table, while in OO theory terms it's one link of a
relation. (In fact that's not completely and invariably true, because
of the weakly-typed nature of link-dirs.) The directory which (by
definition) has as its children every link-directory of a given type
is *not* a link-directory. (It is an ordinary predicate-directory.) In
RDB terms it is the table, and its children are its rows. In OO terms
it is the relation (which makes it a class) and its children are the
links of that relation (the objects which are instances of the
relation).
Second, in the coming examples, assume that the present working
directory can be set to any name, those of ordinary atomic files
as well as those of link- and predicate-directories. This isn't
essential to anything that follows, but it does make things more tidy.
The ability to list the pathnames of a given file makes it useful to
have the pwd point to an atomic file: a command, say
$ ls -P
, can list (some of) the parents of the current file, whether or not
it is a directory. The change also creates consistency with
link-directories, which are non-(predicate-)directory files that can
be the target of the pwd.
On 5/28/05, Alexander G. M. Smith [EMAIL PROTECTED] wrote:
Leo Comerford wrote on Wed, 18 May 2005 12:50:38 +0100:
But if you have relation-directories and the ability to find the
pathnames of a given file, you can do everything you can do with
subfiles, just as nicely, and more besides. And if subfiles are
completely redundant and bad news anyway, we shouldn't have them.
I prefer subfiles (or fildirutes) as being easier to understand. But
maybe that's just due to lots of experience with using file hierarchies.
I can see having a relational system, but I'd always want to also have
a directory hierarchy namespace, so that all files can be named.
Having those relationship directories seems kind of clunky - since
they're not located near the object being investigated. Though
that's a GUI matter of making/(something)/friend the system file browser pop
up a
Show Relationships... menu item as contrasted with drilling down
to a subfile directory listing by clicking on an item.
I'll start with an example here. Imagine a directory,
/(whatever)/portrait
, in which there are portrait photos of a number of men, one photo per
man. Each photo is identified under /(whatever)/portrait by the guy's
first name, so you have
/(whatever)/portrait/Mike
/(whatever)/portrait/Bob
and so on. Now suppose we use link-directories to express father/son
relationships between the guys in the photos. So, for example, if Mike
is Bob's father, we could have
/(something)/father-son/
/(something)/father-son/aardvark:
/(something)/father-son/aardvark:father (which is the file also known
as '/(whatever)/portrait/Mike')
/(something)/father-son/aardvark:son (the file also known as
'/(whatever)/portrait/Bob')
Using these link directories, we can easily express the information in
this (father's-side) family tree:
Mike
| |
v v
--- Bob -- Ted
|| | |
vv v v
Joe DeanEd Todd
, where Mike Bob means Mike is the picture of the father of the
guy pictured in Bob.
But this is where the clunkiness comes in. The family-tree
representation above is an obvious and natural way to conceive of and
manipulate the father/son relationships. We want there to be a
father-son link straight from Mike to Bob; what's more, we want to be
able to list the children (in the graph sense!) of Mike and see Bob
and Ted, and to move leafward from Mike to Bob or rootward from Bob to
Mike. But when we look at how we expressed the information using
link-directories, we see this instead:
--- /(something)/father-son/
| |
v v
aardvark - -- zebra ---
