ServerJS/Filesystem API/Hierarchy: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 8: Line 8:
commot to all fielsystem objects. For instance, we might have <tt>path.exists(), path.isFile(), path.stat(), path.join("/passwd"), path.delete()</tt> and so on.
commot to all fielsystem objects. For instance, we might have <tt>path.exists(), path.isFile(), path.stat(), path.join("/passwd"), path.delete()</tt> and so on.


Then, we have a '''File'''. This class extends Path by adding methods which are specific to files; most notable methods for creation, reading and writing. Similarly, we have a '''Directory''' - File's sibling - which adds (to the Path parent) methods useful for Directory traversal and creation.


One can freely extend this, for instance by creating a Symlink class - its parent would be File. Symlink might offer additional funcionality - methods <tt>symlink.follow(), symlink.edit()</tt> etc.
Note that neither of these objects guarantees the existence of its underlying filesystem representation.


== Examples ==
== Examples ==
# var data = new File("/etc/passwd").open("r").read();
# var data = new Directory("/etc").listFiles();
# var path = new Path("/home").join("ondras"); assert(path.exists());
# var path = new Path("/a/b/c"); <br/> if (path.isDirectory()) { doSomething(); }


== Troubles ==
== Troubles ==


There are still several points in this proposal which make me uncomfortable. Perhaps a different point of view or a discussion can make things clear in this area.
There are still several points in this proposal which make me uncomfortable. Perhaps a different point of view or a discussion can make things clear in this area.

Revision as of 18:20, 26 April 2009

Filesystem Class Hierarchy

This proposal aims to create a set of classes (in an OOP sense) which would add some structuring (and taxonomy) to the Filesystem API. I believe that this can (and should) be done prior to standardizing every available method, including their names, arguments, return values and exceptions thrown.

Basics

Top-level class is a Path. This object (var path = new Path("/etc")) represents a generic path in a filesystem hierarchy. We are not aware of the underlying representation's properties, type (file/dir/link/pipe/socket/whatever), existence etc. Path acts as an ancestor, offering methods which are commot to all fielsystem objects. For instance, we might have path.exists(), path.isFile(), path.stat(), path.join("/passwd"), path.delete() and so on.

Then, we have a File. This class extends Path by adding methods which are specific to files; most notable methods for creation, reading and writing. Similarly, we have a Directory - File's sibling - which adds (to the Path parent) methods useful for Directory traversal and creation.

One can freely extend this, for instance by creating a Symlink class - its parent would be File. Symlink might offer additional funcionality - methods symlink.follow(), symlink.edit() etc.

Note that neither of these objects guarantees the existence of its underlying filesystem representation.

Examples

  1. var data = new File("/etc/passwd").open("r").read();
  2. var data = new Directory("/etc").listFiles();
  3. var path = new Path("/home").join("ondras"); assert(path.exists());
  4. var path = new Path("/a/b/c");
    if (path.isDirectory()) { doSomething(); }


Troubles

There are still several points in this proposal which make me uncomfortable. Perhaps a different point of view or a discussion can make things clear in this area.