John Femiani wrote:
Also
'resource' 'resource_name' 'child' 'child_name'
Hm, regarding parent and child suggestions, considering a path may be something like this: ../../a/b what end is child and parent? Rather than just complaining I throw in what I find natural. I have not really considered how this would effect current users or other useful conventions, so please ignore all that is useless. Otherwise I am glad if it helps. For me the path is something that describe a path *from* somewhere in the graph/tree *to* somewhere which most often is somewhere else in the same graph/tree. It describe a directional traversal between connected nodes in the graph. If the *from* node are special well known places in the graph we have special cases for the interpetation of the file traversal, such as a for the file system root, web server document root and so forth. STL begin() and end() for iterators and front() and back() for access to the elements at each end of the path come to my mind. However which is front and which is back()? When i backtrack a path I, in my head, move toward the front -- arghhh --- so maybe the simple and plain "from" and "to" are best after all. Let us try: path p1("a/b/c"); path p2("a/b/c/d.tar.gz") p1.from_name() == "a"; // path is from directory called "a" p1.to_name() == "c" // path goes to file or directory called "c" p2.to.name() == "d.tar.gz" p1.name() == "c" // name of last node p1.from() == path("a"); // path to first node in p p1.from().name() == p.from_name() p1.to().name().ext() == "" p1.to_name().ext() == "" p1.name_ext() == "" p2.to().name().ext() == ".tar.gz" p2.to_name().ext() == ".tar.gz" p2.to().name_ext() == ".tar.gz" p2.name_ext() == ".tar.gz" p1.to().name().base() == "c" p2.to().name().base() == "d" p2.name_base() == "d" p1.to() == path("a/b/c") // path to last node in p; p == p.to() ??? p1.to().name() == p.to_name() p1.file() == path("a/b/c") // even though a may be a directory ???? in unix all is files :-) p1.file_name() == "c" // only node in p that *may* be a file, a good (but taken) alternative here is basename() p1.file_name() == p1.file().name() p1.file_path() == "a/b/c" // probably not very useful as p == p.filepath() p1.dir_name() == "b" // first directory backtracking path from p:to() p1.dir() == path("a/b") // shorten path by 1 p1.dir().dir() == path("a") // shorten path by 2 *p1.begin() == p1.from() *--p1.end() == p1.to() *(p1.end()-2) == p1.dir() (p1.end()-2)->name() == "b"; This may only feel right if we think of the result of from() and to() as absolute locations, i.e. something more like absolute paths. And that may make sense here, I am not sure. However, if we think of it in context of the path object it operates on rather than the file system the path object may be associated with, it make sense to me. Also, files may only be referred in the path::to() node, the path::from() node and all intermediate nodes in the path traversal must be directories. Symbolic links are just an edge to, or alias to, a directory if it is internal in a valid path. So path::file() may logically be the same as path::to() even if it is not connected to a filesystem with absolute location of the p.from() node defined. Hence, checking on validity of path in general and if last node is a file is not feasible. Operations on a filesystem using a path object may return an invalid value if there is a directory at path::to() location in the filesystem, but that is after the path is put in specific context. -- Bjørn