[e-lang] File API taming

[David-Sarah Hopwood]

ihab.awad at gmail.com wrote:
> Given that the JavaScript API is starting (essentially ...) from
> scratch, what would you think of an API that had the following
> properties:
> 
> - A "File" object is an opaque pointer to a location in the
> filesystem. Its name, extension, or any other information about it is
> opaque.
> 
> - If this File is a regular file, the client may modify, truncate or
> replace its contents.
> 
> - If this File is a directory, the client may enumerate its contents
> by name (relative to this directory) and create or delete Files in
> this directory. In other words, file names are not an intrinsic
> property of the File; they are the names by which they are known to
> the enclosing directory.
> 
> - Notably, the authority to create or delete a File lies only in the
> directory that encloses it.
> 
> This means that it is possible to hand out files (as locations in a
> file tree) without divulging any information about what they are
> called.

A <DirectoryEntry> and a <File> are two distinct concepts.
A <DirectoryEntry> has a filename, creation timestamp, permissions,
etc.; a <File> does not. Also, a <File> might be aliased to several
<DirectoryEntry>s at different locations, or it might not correspond
to any <DirectoryEntry>, because it represents an anonymous stream
such as an end of a pipe or socket, or because all <DirectoryEntry>s
that pointed to it have since been deleted.

Of course programmers can still forget all this (especially the
possibility of aliasing if they're used to systems without hard links),
but making the operation to obtain the <File> pointed to by a
<DirectoryEntry> explicit, gives them a better chance of getting it
right, I think.

> It also, however, means that patterns where I am given a file and I do
> different stuff based on whether it is called "*.exe" or "*.txt" can
> no longer work as simply as before. Who does these anyway, and
> are/were they ever a good idea?

They were never a good idea, but there are some contexts (such as
'make'-like build utilities for example) where this behaviour is
expected by users.

In any case, a design that separates <DirectoryEntry>s and <File>s
can support these usage patterns by passing a <DirectoryEntry> where
needed.

-- 
David-Sarah Hopwood ⚥