From: Darin Adler (darin_at_[hidden])
Date: 2002-01-28 10:31:12
On 1/28/02 7:04 AM, "Jesse Jones" <jesjones_at_[hidden]> 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.
Jesse, I think you are overstating the case a bit when you say that paths
are deprecated on Mac OS and always will be.
There is only one real problem with paths on the Mac OS. For pre-OS-X
versions of the Mac OS, there can be more than one volume with the same
name, so a path doesn't uniquely identify a file.
That's the reason paths were deprecated in pre-OS-X versions of the Mac OS.
Under Mac OS X, paths are not deprecated. Each volume is given a unique name
in the Unix file system while it's mounted, although the
duplicate-volume-name issue still exists within the Carbon file system
interface. There are many OS X native programs that simply use paths and
don't bother with the Carbon FSRef structure at all.
There's a lot more we could say about Macintosh paths and file naming, but
lets not make this more mysterious than it is.
That having been said, if we want a class that supports the pre-OS-X Mac OS
well, then we can't exactly use a "path" class. For this platform, the
volume part of the path must be a vRefNum, not a volume name. And as a side
note, URLs do no better. There's no URL syntax that works on these pre-OS-X
Mac OS systems to uniquely identify a file.
Of course the other things Jesse said are correct; on Mac OS one of the most
important operations on a path is conversion to and from one of the forms
used by the Carbon file system interface, particularly FSRef, but also
perhaps FSSpec and CFURLRef.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk