[boost] Re: boost::filesystem file restrictions

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-08-14 12:05:02

Beman Dawes wrote:
> At 06:03 AM 8/14/2003, Walter Landry wrote:
> It would be trivial to add an additional path constructor that takes a
> checking function or function object.
>
> But that would kill ease-of-use. It is one thing to require an
> additional constructor argument in the fairly limited use "native"
> case, but the portability checking is applied to each and every path
> object constructed, including the many path temporaries created by
> the automatic conversions
> from char * and string.

You could have the checking functor as a pointer to a boost::function which
is a default argument initialized to 0. That wouldn't kill ease of use or
change anything for the users who are very happy with the current posix
default.

>
> (That "kill ease-of-use" point might be hard to understand if you
> haven't actually written code using the library. The automatic
> conversions really
> do allow "script-like" programming ease, and are reasonably safe
> given the conversion result is class path.)
>
> Also, the portability checking policy often needs to propagate to
> called functions such as third party liberties. Adding overloads of
> functions to take an additional argument is also too messy, and
> doesn't provide for automatic pass-through to lower level functions.

I think this is an excuse for a certain amount of additional rewriting of
the library. How you propagate the functor pointer is your own business but
we all have been faced with problems like this when adding a new feature to
an implementation. Internally, do what you need to do but for the end-user I
think you need to consider what is best and most flexible for him.

> In most (but not all) programs it really would be convenient if
> portability checking policy was a global. But of course we all know
> that "global variables are consider harmful". There are also several
> valid use cases where a program needs to switch back and forth
> between portability policies.

Yes, not all portability policies need to theoretically be the same. There
are cases when an OS accepts a file name in one instance, such as
iteratoring through wildcard names, whereas another instance it does not
accept the same notation, such as determining whether or not a specific file
exists. So I think you need to allow portability policies on an instance by
instance basis.