Re: [boost] [filesystem] "leaf"

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-05-29 17:04:04

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