Re: [boost] Thought on paths

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

At 01:05 PM 1/28/2002 +0000, you wrote:
>----- Original Message -----
>From: "Daryle Walker" <darylew_at_[hidden]>
>Subject: [boost] Thought on paths
>
>
> > So the path objects shouldn't store the path as a single string
> > that needs parsing, but as a list of intermediate directory
> > names, the final object, and possibly the volume designator and
> > other data.
>
>We still need to provide some way for a user to type in a path and
>have the program derive other valid and related paths from it.
>I assume the user input will be plain text, so this only really
>changes when we do the parsing. An early parse might allow more
>re-use within the library code, but it won't change the interface.

I agree, how it is stored is immaterial to the interface. In practice, I 
find it better to store it as a string since that is the way I want to use 
it. This way I don't have to rebuild it every time I want to open a file.

>I think the discussion so far has shown that we are a long way
>from an interface that makes sense on non-UNIX systems. (I consider
>Windows to be unix-like.)

I don't think we're that far away. The Vax syntax that was presented is not 
that different from the others, it just uses different separators. The 
version number is a little more problematic but I think we could deal with 
it. I still don't understand the Mac issues but hopefully someone else can 
explain that to me better.

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. 
What is the extension of 'myfile.c', does it matter what platform its on? 
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. 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.

>That interface will presumably deal with objects (files) and
>containers (directories, volumes, machine names). An interface
>this abstract probably handles URLs just as easily as traditional
>paths.

The rest of your post has many good suggestions. However, I think that they 
are related to but not the same as file/path name manipulation. In my mind, 
iterating through directories might use a pathname class but is not 
necessarily the same class. The same holds for attributes, shares, links, etc.

One side note, I don't think it would be possible to iterate http://*/* 
even if I dared. If the pathname class extended to URLs then how do you 
handle iteration. The URL given looks similar to a path but you can not use 
FindFirstFile on it. Even if you write a custom HTTP handler, there is no 
way to get a list of all the files at a given URL that I know of. Even on a 
smaller scale, can you iterate through 
http://stewart.simwright.net/sample/. There are a handful of files there 
but I don't think servers are generally configured to respond to wildcards. 
It would be very neat though if you could handle it, based on the protocol, 
for instance ftp://.... would iterate through files on an FTP server 
instead of using FindFirstFile. The iterator class would have to be a 
factory that returned the correct type of iterator.

Jason