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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk