Re: [boost] Thought on paths

From: Jason Stewart (res0054p_at_[hidden])
Date: 2002-01-28 11:09:17

> > 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.

I am sensitive to the cultural issues. However, these are application 
concerns not library concerns. The library would never add funny dots to a 
filename. However, if the application specifies a path as "myfile.foo" then 
the library should not prevent that. Similarly, I don't think it is 
practical to translate extensions on DOS 8.3 systems (is anybody still 
writing C++ code on these? ;-). If the application specifies a filename as 
mypic.jpeg then DOS would simply use mypic.jpe. We cannot translate this to 
the more reasonable mypic.jpg because we don't know enough about the 
application.

> > 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?

See Darin's message for more information but my understanding is the 
original application could not open the file but you could still open it at 
a lower level using the C++ fopen for instance.. However, this is 
manipulating the file, not the name.

> > 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.

I have never proposed that we not be able to use the filenames to open 
files. That would be useless. However, even on Macs, if I specify 
MyPic.jpeg I can open that file regardless of whether it is actually a JPEG 
file or not. The file type is used by the system to determine the 
application to load.

>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?)

I agree completely. I would not want to use a system that prevented drive 
letters for instance. This would not be useful. However, having an 
extension function that returned the part of the name after the last period 
would not prevent this. It just wouldn't be useful to a Mac (classic) 
programmer. A similar argument could be made for a version function that 
returned the part after the semicolon on a Vax. However, it may be worth 
looking at an extensible mechanism for things like this so that another 
filesystem could have different parts.

>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.)

Absolutely, a pathname class should not impose any particular format but it 
is possible to write one that supports most of the types used without 
enforcing any one of them. As much policy as possible should be pushed into 
policy classes I think.

Jason