RE: [boost] Re: pathname manipulation

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-02-01 08:26:51

From:	mfdylan [SMTP:dylan_at_[hidden]]
> 
> Or even within a particular platform.  For instance Windows Explorer 
> generally treats anything after the *last* dot as the file 
> suffix/extension, but in a lot of cases it makes far more sense to 
> use everything after/including the *first* dot of the filename as the 
> suffix.  There are a growing number of software packages around these 
> days that use multi-part suffixes, and it's often the first part of 
> the suffix that's more important, eg some CAD packages use 
> my_file.prt.1, my_file.prt.2 etc for different versions.  In this 
> case the 'prt' is the important part,  Windows Explorer however 
> thinks these are '1' and '2' files...
> Likewise config. mgmt. software often added extra suffixies - 
> ClearCase uses .keep and .config plus versioning, so something like 
> my_file.cpp.keep.2 is not uncommon.  In this case I would like to be 

There's also the very common foo.tar.gz, for which both suffixes are
important, depending upon the context.

> able to determine all the different "suffix" portions, with a way to 
> specifying as to what the "whole suffix" is.

Reasonable.

> And how are .config files in Unix with no basenames to be treated?  

I should think the basename would come back empty.  That is, I think of such
files as having a suffix but no basename.

> On possibility would be for a suffix() call that took either no or 
> one argument:
> 
> pathname p("/home.dylan/file.cpp.keep.1");
> assert(p.suffix() == ".cpp.keep.1");

I wouldn't expect the first dot to be part of the return value:

    assert(p.suffix() == "cpp.keep.1");

> assert(p.suffix(1) == ".cpp");
> assert(p.suffix(2) == ".keep");
> assert(p.suffix(3) == ".1");
> assert(p.suffix(-1) == ".1");
> assert(p.suffix(-2) == ".keep.1");
> assert(p.suffix(-3) == ".cpp.keep.1");

I don't understand why you're showing positive and negative values, but I
wouldn't find this very friendly.  How do I know which value to pass to the
suffix() mf?  I could see querying the object for the number of suffixes and
being able to iterate the suffixes.  I could see asking for the suffix and
getting everything after the policy-dictated first/last/nth dot.

I think of everything after the first dot as the suffix, but that the suffix
may be comprised of several sub-suffixes, for lack of a better word.  Thus:

    assert(p.suffix() == "cpp.keep.1");
    pathname::suffix_iterator it(p.suffix_begin());
    assert(*it++ == "cpp");
    assert(*it++ == "keep");
    assert(*it++ == "1");
    assert(it == p.suffix_end());

Alternatively, pathname::suffix() could return a suffix object that provides
its own iterator and has some sort of conversion to std::string (which could
be a conversion operator or, more likely, a to_string() mf).

> Likewise for basename
> 
> p.basename() = "file.cpp.keep.1"
> assert(p.basename(1) == "file");
> assert(p.basename(2) == "file.cpp");
> assert(p.basename(3) == "file.cpp.keep");
> assert(p.basename(4) == "file.cpp.keep.1");

I don't think that is very useful.  I'd prefer simply:

    assert(p.basename() == "file");

> but also (in the tradition of POSIX basename)
> 
> assert(p.basename(".1") == "file.cpp.keep");
> assert(p.basename(".cpp.keep.1") == "file");
> assert(p.basename(p.suffix()) == "file");

Perhaps there's a good case for this logic, but that functionality is
certainly possible by iterating the suffix and appending the desired pieces
back onto the basename as I've defined it.  I can't think of a situation in
which the POSIX basename functionality would be valuable, but obviously the
POSIX folks thought it was useful.  Can someone give examples of its value?

Provided there is good use for this functionality, I can see offering
support for it.

> Only then you need a separate function to modify the basename 
> (modify_basename?) which I don't think is a big deal (I've never 

If pathname::basename() works as I've suggested, then naming a mutator
"basename" will work fine, and it will be obvious which part of the pathname
you're manipulating.  If pathname::basename() provides support for the
POSIX-style of indicating the suffix that may be stripped, then the mutator
would need to take the same string parameter to indicate the suffix so it
may be ignored when changing the basename substring.

> liked the policy of using a property name as a 'setting' function.  

I do like it.  I don't care much for the get/set-style prefixes, whatever
you may use.

> assert(p.dirname() == "/home.dylan");
> assert(p.dirname().dirname() == "/");
> assert(p.dirname().suffix() == ".dylan");
> assert(p.suffix().suffix() == ".cpp.keep");

It certainly makes some sense to have such functions return pathname
objects, as illustrated here, but I should think the most likely use of the
return value of any of the pathname accessors (like basename() and
dirname()) is as a string.  Thus, I think these functions should return a
string, and if one wanted to do the operations you've shown above, it would
look like this:

    assert(p.dirname() == "/home.dylan");
    pathname q(p.dirname());
    assert(q.dirname() == "/");
    assert(q.suffix() == ".dylan");
    pathname r(p.suffix());
    assert(r.suffix() == "cpp.keep");

Rob
Susquehanna International Group, LLP
http://www.sig.com