Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-20 07:26:33

Christian Holmquist wrote:
>
> >   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?

Maybe.  I was thinking that set_os_path() might retain the path and upon query, via get_os_path(), validate the directory.  Thus, the directory need not exist when set_os_path() is called; just when get_os_path() is called.  (Filesystem could cache whether the path was validated to avoid doing so on each query.)

Likewise, I was thinking that set_os_path_from_environment() might save the e-var and leave to get_os_path() the job of accessing the e-var and, if it exists, validating the pathname given by it.

Thus, the program could modify the environment or create the "OS directory" in question after having called set_os_path*().  Is such laziness really needed?  No.  Would it be helpful or convenient?  Perhaps.  It was just a passing thought when I added set_os_path_from_environment().  However, to accommodate such behavior, the names really shouldn't begin with "set_os_path" as they wouldn't set the path so much as the policy for finding it.

> set_os_path(X, boost::getenv("Y")) would suffice IMO, surely
> boost must somewhere have a string getenv(string) (?)

If that's all that set_os_path_from_environment() entails, I quite agree with you.  If it were to do more, as suggested above, then no.

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

Sure.  The reason to put such a thing in the library is just to remove the burden from the clients that would avail themselves of that behavior.  Are there enough to justify it?  I don't know.

> Installing a callback function seems a little over-engineered,
> what would be the benefits?

That would allow initialization code to establish the policy in one place while querying code elsewhere benefits.  Filesystem can just store a path against each possible query and leave all else to the client via an eager set_os_path().  That would, of course, require that the initialization code first create missing directories, etc., and then call set_os_path().  Delaying the work, via a callback, means that the reaction to missing directories or e-vars can be handled or reported using an otherwise fully initialized application, so the handling can, for example, make use of GUI facilities that might not be available during initialization.  Again, I don't know whether that will prove useful to anyone, but that was the thought that passed through my head when I suggested the idea.

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

There are other views of what initialization may do.

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

Right, but the means of setting the path could be lazy or eager.

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