Re: [boost] Mac OS deprecating paths

From: joel de guzman (djowel_at_[hidden])
Date: 2002-01-28 11:15:17

----- Original Message ----- 
From: "Darin Adler" :

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

I don't see anything about deprecating paths on MacOS in Jesse's post.
He said "OS's now and in the future". I am not aware of any OS now that
deprecates paths, but it is certainly possible in the future. Path manipulation
is frowned upon on the Mac though because it is simply not needed.

I agree with Jesse. The path should be an implementation detail and the 
internal platform dependent format should be hidden and abstracted from
the client.

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

Indeed. What I suggested was "a standard well defined format such as a URI". 
If a URI is not good enough, we need to define something better here and now. 
If a URI is not good enough, neither will be a unix/dos/vms/macos path hack.
I believe that a common resource identifier format should be *formally* designed 
and specified. What was once thought of as paths should be called a CRI instead. 
Such a specification will be of great value to all and will solve the multitude of
formats problem.

--Joel