[boost] Re: New design proposal for boost::filesystem

From: David Abrahams (dave_at_[hidden])
Date: 2004-08-30 18:17:49

Carlo Wood <carlo_at_[hidden]> writes:

> On Mon, Aug 30, 2004 at 12:12:58PM -0400, Beman Dawes wrote:
>> >My idea is therefore that there should be two types:
>> >- An absolute/native path type
>> >and
>> >- A relative/portable path type
>> 
>> We looked at that approach during initial design, and it just didn't work. 
>> The added complexity was really messy, yet the benefits were few.
>> 
>> For example, what does the signature of the exists() function look like if 
>> there are two path types? Do we now need two exists() functions? What about 
>> functions that take two path arguments? Do those now need four versions? 
>> That might just barely be acceptable in the filesystem library itself, but 
>> you couldn't inflict that sort of argument explosion on user code. Instead, 
>> you would need a base class. That adds complexity. It just gets too messy, 
>> and tests to break use cases we really want to work. We really want the 
>> user to be able to write:
>> 
>>   if fs::exists("foo") ...
>> 
>> rather than:
>> 
>>   if fs::exists(fs::relative_path("foo")) ...
>> 
>> --Beman
>
> My idea on this was (and still is) that it is possible to convert
> a relative path to an absolute path (automatically) by adding an
> absolute path object reference to the relative path object.
> This should make sense in every application imho.

It seems to me that some APIs might very well want to use an interface
that can be statically checked for absolute paths, because relative
paths can be so vague (and not safe from race conditions).  Carlo's
idea appeals to me for that reason as well.  

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com