From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-08-04 01:51:07
Reid Sweatman wrote:
>> > Another option might be: "create_directory_and_parents"
>> > That name is longer than "create_directories" although it better
>> > describes the function.
>> I like "create_directory_path"
> That one's good, and captures the essential distinction well. Other
> possibles: "create_full_directory," or "create_rooted_directory." Dunno.
> On whole, I might prefer your choice. Although it again lengthens the
> name, "create_directory_and_path" captures another minor piece of the
> distinction. You could also play with the distinction (none save semantic
> in most file systems) between "pathname" and "filename;" a filename is
> usually just the thing at the leaf-terminal end of the path (and needn't
> be a "file," save as a directory is often actually implemented as such),
> while the pathname is the full Monty.
FWIW, I don't like
- "create_full_directory", because I don't understand what it means for
directory to be full. "Full of files" is one interpretation which is not
- "create_rooted_directory", because I don't know what's "rooted" directory.
- "create_directory_and_path", because how if one can create directory, one
can name that directory, and the path should already exist.
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.
> In the original scheme, I would think the problem with
> "create_directories" is that it would seem to imply (to me, at any rate)
> the creation of multiple
> directories at the same depth in the file system. Anyway, them's my
> Reid Sweatman
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk