From: Jesse Jones (jesjones_at_[hidden])
Date: 2002-01-28 10:04:32
At 8:56 AM -0500 1/28/02, Jason Stewart wrote:
>>Aren't paths an implementation detail? What about OS's now and in the
>>future that deprecate paths? I don't see why we can't create a higher
>>level class that works just as well as a path-centric class, but also
>>works well on the Mac OS.
>I'm a little unclear on this. Admittedly, I haven't used a Mac since
>'89 or so (not because I don't like them, simply not in my job
>description), and its been even longer since I used a Vax. But there
>have been several references to paths being deprecated on the Mac. I
>don't completely understand what you use instead. I saw a reference
>to FSRefs and searched on the web. As far as I can tell it is an
>opaque data type used to identify a file.
>It seems to me that somehow the user must be able to specify a
>"path" to a file in any hierarchical filesystem. The user cannot be
>expected to specify the inode.
FSRef's are normally created by the system using an OS dialog that
allows users to pick a file/directory or by asking the OS for an
FSRef to a well known directory like the preferences directory. Apart
from developers and the occasional power user on OS X users never
type in paths.
>I went to Apple's website and did a little research (only about 5
>minutes worth so I could have easily missed a lot). There, I see
>several references to path names, hierarchical
>filesystems,directories, etc. An example from one of their pages:
>/Mac OS X/
>The looks like you could easily specify a path as "/Mac OS
>X/Users/Steve/Documents/" to find a file located in Steve's
Sure, even on OS 9 you could use paths although it would be a bit
awkward because the system API's expect FSSpec's or FSRef's. But
there aren't many Mac programmers who are going to be willing to use
>To me, it still looks like it would be useful to have a class that
>manipulates theses paths. You might want to iterate through the
>pieces that make up this path, or get the root volume, or change the
>last directory entry, etc.
Mac programmers make very limited use of paths so a class that
manipulates them is nearly useless.
>The main point of this class is manipulation of the pathname strings,
And my argument is that the purpose of a boost class should be to
manipulate objects that act as pointers to files and directories. If
these classes are carefully written I think they can be as easy to
use as something focused on paths yet abstract enough to work well
with something like an FSRef. The OpenDoc framework did something
very much like this. (I've written a Mac/Win framework that borrowed
a lot of ideas from the way ODF handled file systems).
>not actually file manipulation. I think that is a different problem.
Right, reading/writing data, meta-data, permissions, and similar
things belong in different class(es).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk