Re: [boost] the first version of abstract path manipulation class (interface)

From: Jani Kajala (jani_at_[hidden])
Date: 2002-01-24 12:30:18

> - I suppose it is reasonable to allow for ".", "..", and "/" in pathname
> strings as standard notation that might get translated into
> platform-specific delimiters, but I wonder how folks that work on other
> platforms would feel.

Could you explain more what you mean? I don't see any problem in using ".", ".."
or "/" with the path class.

> - I don't understand what an "abstract" pathname is.

'Path name' can be the name of a file or a directory. The name is 'abstract' in
a sense that it might not be even valid file/path name for given platform.
Example: Windows/DOS does not support '/' as separator, even though every C
library on the platform happens to do it for compatibility. I think it is good
to make distinction which is platform specific name and which isn't.

> - "last_modify" should be "last_modified."
> - "last_access" and "last_modify" should return time_t

I agree, those are better names.

> - In Unix, files have suffixes, not extensions, so I wonder whether there
> should be a "suffix" mf, too.

suffix() actually sounds better, and it's shorter too. Maybe extension() should
be replaced with suffix().

> - There are more attributes available, via stat(), under Unix than you have
> accessors for. What if I want to know whether the sticky bit is set?

struct stat buf;
stat( p.norm_path().c_str(), &buf );
...

> - There is no information available on file permissions.

Neither has C or C++. :)

> - "list" is poorly named; how about "subdirectories?"

list() does not list only subdirectories, it lists all files also (it does not
recurse).

> - "list" should take an output iterator, allowing the caller to determine
> the most appropriate container type.

I kind of agree.. This complicates list() a bit since platform specific headers
need to be avoided by adding extra level of indirection, but it is still a good
change.

> - Accepted terminology for pathname components are: pathname, filename,
> basename, extension/suffix, parent, child, subdirectory.

'Accepted' depends much from the point of view. I find name() more descriptive
than basename(), maybe because file/path names make up a hierarchy, and if you
think of 'base class'... You probably get my point.

> - "norm_case" should be a variant of "abstract." That is, "abstract" should
> be overloaded or have a default parameter that controls whether to normalize
> the pathname's case.

Uh? As the documentation says, 'normalized' path names are platform dependent,
'abstract' path names are not. Maybe the documentation about used terminology
should be clarified? Besides, having different functions doing different things
is cleaner and less error prone. Or what about C realloc...

> - In DOS/Windows, pathnames are case insensitive, but they are stored in
> upper case, so "norm_case" returns the wrong case. Other case insensitive
> platforms may conventionally use lower case, so this should be configurable.

The whole idea of norm_case is that by using the function you know what case it
will return if the platform does not make a difference between uppercase and
lowercase. I think there is no 'right' or 'wrong' casing here.

> - I don't understand what "norm_path" does that "abstract" doesn't. (I don't
> know what either function does.)

norm_path converts the path name to platform-dependent form -- in Windows/DOS it
converts forward slashes to backslashes.

> trying to get a list of subdirectories from a file will throw an exception,
> but it suggests that you're combining incompatible things.

As the documentation says, list() returns "Number of files in the directory. 0
if abstract path is not a directory." There is no exceptions used anywhere.

> Instead, why not separate path manipulations from file/directory operations?

Because you can't completely separate those. For example how can you provide
absolute path name of "./" without accessing file system in any way? Of course
you can consider absolute paths as 'file operation' but there would be not be
much use for path name manipulation without such basic functionality.

For other references about path manipulation, see for example java.io.File class
and the Python link which Dave posted. I think you find functionality of the
path class very much similar to approach taken by those languages (it's not a
coincidence of course). I think it is important to try to avoid reinventing the
wheel here.

Regards,
Jani Kajala