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: Beman Dawes (bdawes_at_[hidden])
Date: 2010-02-18 13:26:57

On Thu, Feb 18, 2010 at 10:35 AM, Stewart, Robert
<Robert.Stewart_at_[hidden]> wrote:
> Beman Dawes wrote:
>>
>> Important differences from the prior version:
>> http://mysite.verizon.net/beman/v3/v3.html
>
> I just looked through this page and have the following comments:
>
> "stem" means nothing to me.  I followed the Reference link to the path class documentation and find no description of it there.

Added a direct link to the reference doc description. Added an example
to the reference doc description.

> complete(), even though the term is odd versus the normal "absolute" terminology, works well because "complete" can be a verb.  OTOH, absolute() is bad because "absolute" cannot be a verb, so it makes a bad function name.  IOW, it should be named "make_absolute."

Interesting. I went back and forth between "absolute" and
"make_absolute", but the verb argument didn't occur to me. I think
that's enough to swing the decision to "make_absolute".

>
> Similarly, unique_path() is poorly named because "unique path" is not a verbal.  The function should be named "make_unique_path."

I also considered "make_unique_path", but worried that people might
expect the actual path to be created in the external file system,
rather than just returning a path object. Does that concern you, or do
you still consider "make_unique_path" better?

> Typo: "To ease the transition, Versions 2 and 3 will both included...."
>
>   s/will both/will both be/

Fixed.

>
> Why the ellipsis with the yellow background?

I use a yellow background to for text that needs improvement. ... is
just a place holder.

> When looking at the path query functions to learn about "stem," I found the *painfully* highlighted "Deprecated convenience functions" section.  I have comments on what's revealed therein:
>
> You state that extension() returns the period to allow distinguishing between an empty extension and no extension.  That seems wrong.  Typical use cases for working with the extension will require stripping the period before proceeding, so you push extra work onto the client.  Furthermore, I can't think of a case in which extension processing code would work differently when there is no extension and when the extension is empty.  The extension is an empty string in both cases.  Since you already provide has_extension() for distinguishing that there is one, extension() should return an empty string when nothing follows the period.

IIRC, that was Volodya's original design and I can't recall anyone
ever complaining about it. True, we didn't have the has_extension()
function, but still, I hate to break existing code. Does anyone else
have a strong opinion?

>
> change_extension() requires that the client prepend a period to the new extension string.  Why is that necessary?  I can imagine several use cases in which the extension would be found without a leading period.  The client code would then have to prepend a period to use change_extension().  Also, if you change extension() as I note above, then it will return the right value for change_extension()'s second argument.

Again, I'm concerned about breaking existing code. I'm willing to do
that for V3, but only if I become convinced it results in a real and
noticeable improvement.

Thanks for the comments!

--Beman