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: Beman Dawes (bdawes_at_[hidden])
Date: 2010-02-20 06:47:45

On Thu, Feb 18, 2010 at 1:39 PM, Peter Dimov <pdimov_at_[hidden]> 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
>
> On POSIX, it's even more important to retain the period, because "foo" and
> "foo." refer to different files.
>
> 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.
> 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).
>
>>> 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

Convincing arguments. I've added a link to this message in the
extension() reference docs.

Thanks,

--Beman