On Fri, Feb 6, 2009 at 22:32, Kenny Riddile <kfriddile@yahoo.com> wrote:
Also, may I suggest the name "as_relative_to" for the member function if this is added to the library? as_relative_to would be a const member method that take the desired base path as its only parameter and returns the desired relative path.
The problem I see with that is that to handle symlinks elegantly, "uncomplete" will need to look at the filesystem, not just the path elements, which, following as I understand the way things are organized, prevents it from being part of the path class itself. (This is the same problem that keeps coming up: ./foo/bar/.. doesn't have to be ./foo when symlinks are involved.) In any case, it's the inverse function to complete, so it should be the same kind of beast. (It seems p.has_root_path() ? complete(relative(p)) : relative(complete(p)) should be equivalent to p, assuming compatible root_name()s in the first branch.) As I mention in the ticket, I really like the idea of calling the function relative, but I'm worried about conceptual conflict with the relative_path() decomposition function (which I don't really like, since if complete uses initial_path, it seems like relative would be to initial_path, not to the root of the path in question, though the member/nonmember may be enough to disambiguate).