RE: [boost] Re: the first version of abstract path manipulation c lass (interface)

From: Jason Stewart (res0054p_at_[hidden])
Date: 2002-01-25 10:20:03

>My point was that an application trafficking only in 8.3 names -- could
>there still be any? -- would expect to work with upper case pathnames.  If
>there's some other OS with some other naming convention, then it would be
>ideal to support that convention, and less the exact conventions of various
>versions of Windows.

The important thing is that we cannot force uppercase on windows because 
most modern software doesn't expect/want all uppercase. Most users think 
"old" when they see software that doesn't preserve case. It sounds like we 
agree on this.

>I don't want to further complicate matters, but I have to ask:  Are there
>any platforms that use more than a single character as the separator?

I don't know. I can't think of any but if someone does let me know.

>"transform" doesn't evoke the purpose of the function fully to me.  How
>about "to_native" or something like that?  Yes, it potentially transforms
>one representation to another, but the point is to turn some common
>representation or variant into the standard, native representation.
>
>Does the "transform" logic take a string and return another?  If so, would
>it be better to have a function that takes a character and returns the
>transformed character?  Then, the pathname class can walk the string and do
>an in-place update of the string, avoiding a copy.  That also makes the
>policy class simpler.

Both policies have a transform. The case policy's transform takes a string 
and returns a string. If you wanted to do title caps for instance, it seems 
difficult to implement by only looking at a single character.

The separator policy takes a single character and transforms it. In my 
applications I tend to transform everything to forward slashes. Windows 
functions handle them fine and unix programs usually don't (including 
cygwin). However, some programs might would rather leave the separators as 
is. I included an AgnosticSeparator that doesn't change them.

>When checking for duplicate separators, does the policy class' function do
>the work or does it simply indicate whether duplicates are permissible?  The
>latter would leave the string manipulation work in the pathname class,
>making the policy class simpler.

The traversal is done in the Pathname class. The policy gets two characters 
and returns true if they are redundant (usually if isSeparator is true for 
both). However, if you wanted to allow multiple consecutive separators you 
could always return false.

> > Also, this class doesn't do much file I/O, it is solely for pathname
> > processing., not directory processing. From some of the other messages
>I've
> > read, people seem to feel this is the way to go.
>
>What file I/O is needed for pathname processing?  What aspect of pathname
>processing am I missing that you feel is needed in this class and requires
>filesystem access?

Actually, the opposite is true. I don't feel that the class should do any 
I/O. There was some debate earlier about whether things like attributes or 
iteration should be in the pathname and I feel like it should not. I think 
the class is easier to understand if it just implements parsing and 
manipulation.

I have written some other functions (FileSystem namespace) that work with 
my Pathname and Filename classes. I try to put all of the I/O in there or 
write separate classes for iteration, recursion, and attributes.

Jason