> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams > Sent: Sunday, August 03, 2003 7:15 PM > To: [EMAIL PROTECTED] > Subject: [boost] Re: Filesystem: create_directories > > > Thomas Witt <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
