[e-lang] File API taming

[ihab.awad at gmail.com]

Hi folks,

In our discussions about a possible file taming for JavaScript, MarcS
directed us to the E taming. The E taming, about which I was reading
here:

 http://www.erights.org/javadoc/java/io/File.html

seems to treat the absolute String path of a file as public
information available to anyone. What it *does* restrict is the
ability to start from this data and turn it into *authority* -- in
other words, the ability to create a File from a fully qualified path
is tamed away.

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.

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?

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA