Re: [boost] Thought on paths

From: Ken Hagan (k.hagan_at_[hidden])
Date: 2002-01-28 10:20:41

----- Original Message ----- 
From: "Jason Stewart" <res0054p_at_[hidden]>

> Extensions don't seem that problematic to me (maybe I'm glossing
> over too much). Yes, extensions have no general meaning on UNIX,
> but technically they don't on Windows either. The shell attaches
> meaning to them but I can make up my own without problems. Many
> UNIX programmers use them anyway.

I think this ignores two minor problems. The first is that there
may be a cultural aspect to the extension. For example, on OS'es
that haven't used extensions, a well behaved application shouldn't
create filenames with funny dots in them. Secondly there are the
platform differences that we ought to hide. For example, on 8.3
file systems (on any OS) you can't simply append ".html" to a name.

> On Macs there is a file type stored in the file (at least, the
> last time I checked there was) but its not quite the same thing.
> The extensions can specify type by convention on some machines
> but the Mac resource fork specifies the actual type.

I confess my ignorance of the Mac here. If I don't set the type
correctly, is my file "usable"? Should well-behaved Mac apps set
an appropriate type for any files they create?

> The pathname
> class that I proposed earlier deals with manipulating the strings
> in the path, not the actual file. I don't see that harm of returning
> the text after the last period in the filename as the extension
> on all platforms. It just wouldn't be used much on Macs.

I think you've set the scope too narrowly. It isn't much use being
able to parse "filenames" if the resulting strings cannot be used
to create or open the corresponding files on the target platform.
That means we have to look at things like file-types which are only
present on some file systems, but which might be compulsory on those
systems.

There's also a strong argument for a library that can handle *any*
name that is legal on the target platform, so that it can be used
to write a backup utility or with a user-specified filename. (What
could be more infuriating than a program which can't find a file
even when you type the name in by hand?)

To a lesser extent, a platform-neutral library should also generate
pathnames that follow the accepted conventions of the platform.
(Look at the discussion of a command line parser, where folk are
getting worked up over supporting the "usual" syntax on their OS.
Getting the culture right matters.)