ServerJS/Filesystem API/Hierarchy: Difference between revisions
(Created page with '= 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.') |
|||
| Line 1: | Line 1: | ||
= Filesystem Class Hierarchy = | = 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. | 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 (<tt>var path = new Path("/etc")</tt>) 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 <tt>path.exists(), path.isFile(), path.stat(), path.join("/passwd"), path.delete()</tt> and so on. | |||
== Examples == | |||
== 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. | |||
Revision as of 18:12, 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.
Examples
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.