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.
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. 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. The main point of this class is
manipulation of the pathname strings, not actually file manipulation. I
think that is a different problem.
I freely admit my ignorance here so please help me understand what level
you are talking about.
Jason