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

Subject: Re: [boost] [Filesystem V3] Filesystem Version 3 beta 1 availablefor download and comment
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-02-18 14:26:53

Peter Dimov wrote:
> Beman Dawes wrote:
> > On Thu, Feb 18, 2010 at 10:35 AM, Stewart, Robert
> > <Robert.Stewart_at_[hidden]> wrote:
>
> >> 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?
>
> It is the right design to retain the period, IMO, and most
> "get extension" functions do so, even on Windows, where there is no
> difference between "foo" and "foo." when actually used to refer to
> a file. See for example
>
> http://msdn.microsoft.com/en-us/library/e737s6tf%28VS.100%29.aspx

That's an interesting precedent, but that strikes me as wrong, too!

> On POSIX, it's even more important to retain the period,
> because "foo" and "foo." refer to different files.

I can see that creating "foo." from "foo" requires that one be able to set the extension as "." and that would require special case code.  Perhaps the right solution is to prefix the argument with "." when omitted?  That way, existing code, which provides the "." will continue to work, while code that has the extension, but no period, can work henceforth.

That works for setting an extension, such as with change_extension(), but doesn't address what extension() should return; see below.

> There are two main reasons to retain the period. First,
> client code may wish to distinguish between "" and "." as
> extensions, in order to, for example, append a default
> extension only in the "" case, where one is not supplied.

That's easily done using has_extension() as I mentioned.

> Second, and this also applies to retaining the trailing slash
> in the  directory name, to provide the ability to reconstruct
> the original path by concatenating its elements (directory,
> name, extension).

With my "optional period" suggestion above, that wouldn't be a problem.

> >> 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.
>
> This is also the correct design, for consistency with the
> above. Changing the extension to "" and "." are different
> operations. Again, existing practice requires the dot even
> on Windows, see for example
>
> http://delphi.about.com/library/rtl/blrtlChangeFileExt.htm

Another bad precedent! :-}

My "optional period" suggestion works here, too.

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