[boost] Re: Filesystem: create_directories

From: Jeremy B. Maitin-Shepard (jbms_at_[hidden])
Date: 2003-08-04 20:07:52

On Mon, 04 Aug 2003 10:51:07 +0400 Vladimir Prus <ghost_at_[hidden]>
wrote:
[snip]
> >> > Another option might be: "create_directory_and_parents"
> >> > That name is longer than "create_directories" although it better
> >> > describes the function.
> So, to summarize, I've no problem with the current name that I've
> introduced. Of other suggestions "create_directory_and_parents" looks
> best to me. "ensure_directory_exists" does not imply any operational
> semantic(i.e. the name does not say that the directory will be
> created. One might expect exception to be thrown if dir does not
> exist). "demand_directory" is good. One problem is that "demand" still
> does not communicate to me that something will be created.

I suggested "create_directory_and_parents" because the current
"create_directories" has exactly the semantics of calling
"create_directory" incrementally on each parent directory path, then on
the directory path itself.  It could be called
"create_parents_and_directory," but it is useful to emphasize
the relationship with "create_directory" since both functions have the
same post-condition and many existing libraries provide this
functionality based on a parameter to a single "create_directory"
function.

On a separate note, the current create_directories documentation uses a
non-existent function "is_parent" in the precondition specification. 
Perhaps this function should be defined in "convenience.hpp" also.  A
name that explicitly conveys the order of the arguments is:
"is_parent_and_child"

Grammatically, "are_parent_and_child" is correct, but it would be
inconsistent with the type_traits library and does not sound
better.

-- 
Jeremy B. Maitin-Shepard
jbms_at_[hidden]