On Mon, 04 Aug 2003 10:51:07 +0400 Vladimir Prus <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost