RE: [boost] Re: Filesystem: create_directories

From: Reid Sweatman (drunkardswalk_at_[hidden])
Date: 2003-08-04 05:04:13

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of David Abrahams
> Sent: Sunday, August 03, 2003 7:15 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Filesystem: create_directories
>
>
> Thomas Witt <witt_at_[hidden]> writes:
>
> > I'de like to get away from create. As I understand it, what we really
> > want is to make sure a directory path actually exists without
> > necessarily creating any directories. To me calling a create function
> > for something that already exists should be an error. I can't see a
> > reasonable way to have these semantics with create_directories.
> >
> > What about something like this:
> >
> > ensure_path_exists(path);
>
> I have a word I use in scenarios like this: "demand".
>
>   demand_directory(path)
>
> "Demand" is not a perfect fit, but if you treat it like a term of
> art, it works.

And this is the message I referred to in my slightly prior post.  The
distinction here you've already pinned down.  You're right in your final
comment, I think; any word I can think of is just a synonym for "demand,"
like "request," or "return."  This is a place where traditional CS has let
us down; it's a distinction that's been there since there were decent file
systems, but no one ever coined a word to cover the situation, which is
really common.  Gee, I'd have thought Knuth would have invented one, if no
one else <g>.  This feels almost (but not quite) like the distinction
between logical "or" and "xor."  Of course, there, Boole supplied
terminology.  Hmmmn.  It feels *exactly* like a singleton class, in that if
there's not one, you create it, and if there is, you just return it.  In
fact (to go OT a bit), since directories are unique (ignoring aliases), you
could implement this functionality via singleton.  Most of the terminology
associated with singletons doesn't much work here, though.  How about
turning it into a functor?  I guess that's sort of a cheat, inasmuch as it
just dodges the naming issue altogether, and requires the semantics to be
documented somewhere other than in the name.  I don't know as I'd fight too
hard for a solution like that.  Anyway, was pondering, it bubbled to the
top.

To clarify what was something of (two) rambles, I think the issues that need
encapsulation in names are:

1)  Distinction between path and directory
2)  Asking for an object that may or may not exist; ditto its precursors
3)  Default behavior in different cases of (2)

I suppose (3) could be captured via any of several mechanisms; simplest
seems to be overloaded unary and binary versions.

Reid Sweatman