Re: [boost] Mac OS deprecating paths

From: joel de guzman (djowel_at_[hidden])
Date: 2002-01-28 20:13:40

----- Original Message ----- 
From: "Gustavo Guerra" :

> >
> > I'll explain my suggestion again. Instead of manipulating native path
> types
> > which will work on platform X and not on platform Y, nor Z, I suggest
> > using a common, more formal and extensive path akin to URIs. The client
> > sees this and works on this. Behind the scenes, as needed, this is
> > converted to and/or from the underlying native format. The client does
> > not care about this. This "common-resource-identifier" should be rich
> > enough to describe any file-path format in existence as well extensible
> > enough to accomodate any future path formats. Such a formal resource
> > identifier will alleviate the multitude-of-formats problem.
> >
> > I know this involves more work, but it is all worth the effort, IMO.
> >
> > --Joel
> >
> 
> But what's the problem with doing "just" a pathname library now, that
> successfully abstract the native pathnames from POSIX(Unix and new MacOS X),
> Windows and VMS (possibly others)? After that, we can do a CRI like you say
> on top of it, that would take advantage of those weird MacOS FSRef and so.
> Why complicate? There is enough complexity involved in making a pathname
> class already.

That's reasonable. After all URIs are based on POSIX paths anyway. What's
more important in my suggestion is standardize on something and do the 
platform-mapping on the spot on demand. This is the key point in my suggestion. 
What standard to use is secondary (and of course subject to debate :). The 
important thing is that the client does not have to care about the details such 
as "what separator do I use in this platform?", "is this legal in this context?" 
"is it case sensitive here, how about there?" etc. The client has to learn just *one* 
standard and this is mapped automatically behind the scenes on each platform 
where the library is deployed.

--Joel