Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2010-10-19 15:45:47

> enum os_path_t

> > {
> >   path_temp,
> >   path_home,
> >   path_windows_my_documents,  // Or is this too ugly?
> > };
> >
> > namespace filesystem
> > {
> >  path get_os_path(os_path_t)
> > }
> >
> > os_path might not the best name, but you get the idea..
>
> I was thinking of something similar: indicate which directory is wanted by
> a discriminator.  As for names, I'd definitely avoid "windows."  In your
> example, "path_windows_my_documents" could be "path_documents" and still
> serve just as well.
>

Sure, but the documentation must state clearly on which platforms it can be
expected to have a default implementation.

>
> Given that there is no specific My Documents equivalent on POSIX systems
> and no specific home directory on Windows, perhaps the better approach is to
> have calls for those throw an exception unless the application first defines
> their location.  That is, Filesystem could offer a standard API for
> accessing such paths but require the actual path be specified -- once per
> run -- when there's no OS default.  The advantage is that most code can use
> the common API and only initialization code must set the ambiguous paths
> according to some local policy and the current platform.
>
> Therefore:
>
>   namespace filesystem
>   {
>      path
>      set_os_path(os_path_t, path const &);
>
>      path
>      set_os_path_from_environment(os_path_t, std::string const &);
>   }
>
>
>
This I like, but do you need set_os_path_from_environment?
set_os_path(X, boost::getenv("Y")) would suffice IMO, surely boost must
somewhere have a
string getenv(string) (?)

> What's missing is the ability to set a policy that indicates Filesystem
> should try some particular e-var and, if that's not set, check for a
> particular directory, and if that doesn't exist, throw an exception.  That
> would be the most useful.  Perhaps the right behavior is to simply install a
> function that Filesystem can call to provide the path when needed.
>

with set_os_path I think users can do that themselves. Installing a callback
function seems a little over-engineered, what would be the benefits?

>
> It may be handy to provide a feature query function, too:
>
>   namespace filesystem
>   {
>      bool
>      is_os_path_available(os_path_t);
>   }
>
> If get_os_path() calls a user-installed function, then
> is_os_path_available() would have to call the former in a try block, of
> course.
>
>
I thought you were aiming at having filesystem configured at initialization
with set_os_path.
get_os_path() should IMO throw if there's no platform specific
implementation for the discriminator and the user has not explicitly set the
path.

Do you have a particular implementation of such a user-defined function that
would benefit from lazy evaluation? I have a feeling I'm missing your point.

Christian