Re: [boost] [Filesystem V3] Filesystem Version 3 beta 1 available for download and comment

Subject: Re: [boost] [Filesystem V3] Filesystem Version 3 beta 1 available for download and comment
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-02-22 07:23:39

Beman Dawes wrote:
> On Thu, Feb 18, 2010 at 2:54 PM, Gregory Peele ARA/CFD
> <gpeele_at_[hidden]> wrote:
> > Beman Dawes wrote:
> >> On Thu, Feb 18, 2010 at 10:35 AM, Stewart, Robert
> >> <Robert.Stewart_at_[hidden]> wrote:
> >> >
> >> > "stem" means nothing to me.  I followed the Reference link to the
> >> > path class documentation and find no description of it there.
> >>
> > Regrettably the terminology for this is remarkably
> > nonstandard, but I've never heard of "stem" before and would
> > not have had any idea what it returned.  Typically I've seen
> > this called "base_filename" or even just "filename". Where
> > did "stem" come from?
>
> See http://article.gmane.org/gmane.comp.lib.boost.devel/177103

I now understand the rationale for "stem," but I'm not a linguist, so I don't think of "stem" in that sense.  (I think of plants, which is hardly helpful when mapping to a filesystem.)

Here's the terminology I like:

* pathname:  a sufficiently qualified description of a file's
             location
* path:      the possibly empty directory hierarchy necessary to
             locate a file
* basename:  the last component of a pathname that fully names a
             file (from basename(1), of course)
* filename:  can be an alias for "basename" but is often used as
             an alias for what you call "stem"
* extension: the part of the basename following the last period
* suffix: the part of the basename following a first period

The difference between "extension" and "suffix" warrant clarification.  They are based upon experience with Windows and *nix filesystems.  In the former, only the part following the last period actually determines the file type and is reasonably called the extension.  The rest is ignored as being part of the filename.  In the latter, everything added to the initial part of the basename modifies or extends that initial part, so there can be multiple suffixes (the ".tar.gz" example comes to mind).  Whether the set or the parts are considered a "suffix" can be debated.

Given the opportunity to clash with various personal preferences and preconceptions, some of those terms remain troublesome.  What if you used "head," "tail," and "extension?"  That is, basename() could return the last component of the pathname, which could be a type that has three accessors: head(), tail(), and extension().  tail() would return everything after the first period, while extension() would return what follows the last period.  Such a class would likely need a conversion operator to the string type for ease of use and backward compatibility.  You could instead have basename() return the string type, but add accessors: basename_head(), basename_tail(), and basename_extension().  That's uglier in my mind.  A third option is to provide extractors: non-member functions that parse a string to extract the head, tail, or extension.  (That last option is the most flexible as it even works on pathnames and other strings.)

To provide a ready means to navigate multi-suffix sequences, you could extend tail() with suffixes(), which could return a collection or populate a collection via an output iterator.  That is, the collection would then contain one string for every period-delimited string in the tail.

BTW, I consider "filename," "basename," and "pathname" as single words, not compounds of "file," "base," "path," and "name."

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.