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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-25 11:56:41

From:	Jason Stewart [SMTP:res0054p_at_[hidden]]
> 
> >"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.

You're right.  Perhaps the better approach is to take the string by
non-const reference, allowing transform() to do in-place substitutions, even
replacing n characters with m, if the need arises.  The value is simply one
of efficiency, which may be (is?) premature to consider.

> >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.

I recall some version or other of this functionality including certain
stat()-like information, and I asked why there wasn't more, if there was
some.  I also asked that pathname manipulations be separated from filesystem
access, so I think we agree there.

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