Re: [boost] Thought on paths

From: Jason Stewart (res0054p_at_[hidden])
Date: 2002-01-30 08:45:57

At 09:59 AM 1/30/2002 +0000, you wrote:
>From: "Stewart, Robert" <stewart_at_[hidden]>
> >
> > If you're using the Unix/Windows pathname manipulation class, then
> > myfile.foo is quite appropriate.  If you're using the Mac OS X
> > pathname manipulation class, then you wouldn't supply myfile.foo at
> > all, from my understanding.
>
>I think we need to clarify why anyone would want a library for
>pathname manipulation. If I know that I'm targetting a particular
>OS, then there are probably OS-specific library functions or APIs
>that already do the job. If I'm targetting several OSes, then
>I can either use conditional compilation and write the code several
>times, or I use a library that does all that for me.

I know of no cross platform functions for doing this. Microsoft has a 
_splitpath function which is painful to use well. An earlier poster stated 
that everyone and their pet yak had implemented this functionality. This 
implies a general need.

>In the latter case, if I don't supply myfile.foo on the Mac, then
>I won't be supplying it on Unix/Windows either. So what do I supply?
>
> > This isn't the responsibility of the pathname manipulation class.
>
>As I said earlier, manipulating paths is pointless unless the
>resulting paths can be used. That means thinking about how those
>paths are eventually used to create or open files of an appropriate
>type (for those systems that care) for third party apps and with
>"culturally correct" names for the end user.

Again, you are talking about writing data. Tell me how to write the 
resource fork for a "foo" file on the Mac there is more to it than just 
writing ".foo" to a file.

If I were to specify a file called "myfile.foo" then it is just as valid on 
the Mac as it is on the PC. It does not matter what type the file is. As 
far as not allowing extensions on a Mac (or any other platform that does 
not tend to use them), this seems like a harsh policy to enforce. What if 
the user really wants to use a period in their filename? You mentioned 
allowing the user to specify an extension but not the application, but for 
a library, the application is the user. Given the filename "myfile.foo" did 
it come from the user or from the application? I'm all for 
"multiculturalism". I just don't think a library should enforce culture.

>Remember, we already have OS-specific solutions for manipulating
>paths. I wouldn't personally be interested in another one. I would
>be interested in a cross-platform way of storing, mutating and
>using "file system thingies". I'm happy to accept that a path
>parser would be part of that, and that the hard part is done
>elsewhere, but if the hard part can't be done then there is little
>point in providing the parser.

No one has talked about writing an OS specific class. We have talked about 
policies that know how to interpret OS specific paths but the system should 
be cross-platform.

I think I understand the Mac's FSRefs a little better now. But they refer 
to specific files. The point of this class was to provide manipulation of 
filenames/pathnames in an abstract way without using the filesystem. Maybe 
there is some common functionality that can be factored into a higher level 
class though. This needs more input from some of the Mac people on the list 
though, I don't have access to a Mac and haven't used one is a decade. I am 
interested in this aspect though.

Jason