Boost logo

Boost :

From: Gustavo Guerra (gustavobt_at_[hidden])
Date: 2002-01-28 14:19:43

----- Original Message -----
From: "joel de guzman" <djowel_at_[hidden]>

> ----- Original Message -----
> From: "David Abrahams" :
> > ----- Original Message -----
> > From: "joel de guzman" <djowel_at_[hidden]>
> >
> > > The name "path" is misleading. For example in the MacOS,
> > > there are FSSpecs and paths which are different.
> >
> > The question is, are the set of operations similar enough that it makes
> > sense to try to represent FSSpecs with the same cross-platform class as
> > paths? If someone has a program written to manipulate paths on Unix will
> > they be able to apply the same operations on MacOS 9? It might make
sense to
> > manipulate paths on the Mac with this class, since after all they do
> > I am an old Mac guy, but too old I guess: I've forgotten. BTW, does this
> > apply to OS X?
> I'll explain my suggestion again. Instead of manipulating native path
> 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.

Gustavo Guerra

Boost list run by bdawes at, gregod at, cpdaniel at, john at