Re: [boost] Re: the first version of abstract path manipulation class (interface)

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.

Right.

>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/
>      Applications/
>      System/
>      Users/
>          Shared/
>          Steve/
>              Documents/
>
>The looks like you could easily specify a path as "/Mac OS 
>X/Users/Steve/Documents/" to find a file located in Steve's 
>documents directory.

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

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

   -- Jesse
--