From: Jesse Jones (jesjones_at_[hidden])
Date: 2002-01-28 18:32:17
At 7:31 AM -0800 1/28/02, Darin Adler wrote:
>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.
Deprecated is the wrong word. I think frowned upon is still correct though.
>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.
That's one reason. The other reason is that paths are fragile. If the
user moves a file while the program is running bad things will
happen. If the app saves a path in a pref or something and the user
later moves it bad things will happen. This is *bad*: Mac users don't
know about paths or file systems. All they see are icons in the
Finder and they expect to move almost everything wherever they want.
>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.
OS X complicates things. It's essentially three platforms in one: BSD
Unix, Cocoa (the NeXT Objective-C app framework), and Carbon (an
updated version of the Mac OS 9 APIs). These are all native
applications, but only BSD Unix and Cocoa use paths (and Cocoa's
dependencies upon paths are being reduced). I strongly doubt that
many Carbon apps are using paths (and the majority of OS X apps are
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk