From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-21 10:20:59
At 03:35 AM 8/19/2003, Yitzhak Sapir wrote:
> ... numerous use cases ...
>
>My feeling from all these examples is that a path string is inherently
>specific to the system for which it was specified, and can't really be
>ported to anywhere else. Much like a string is usually inherently
specific
>in its encoding to the system-specified encoding. However, the
filesystem
>library can provide a portable way to manipulate this system specific
path,
>much like the string library provides a portable way to manipulate the
>system-specific encoded string. In view of this, why try for a "portable
>path" at all?
There are plenty of use cases where no name portability checking is
required. Some require checking for the generic grammar, but do not require
checking for portable names. There are two variations on not checking for
portable names; (1) doing no checking at all (in class path, which amounts
to deferring the checking to the operations function calls where the O/S
API will do the checking), and (2) doing native checking.
All of you examples fall into those categories.
Then there are a number of use cases which do require some degree of name
checking.
The plan for the filesystem library is to support all of the use cases,
including the ones you identify. The most serious remaining questions have
to do with defaults. But regardless of how those defaults turn out, all of
the use cases will be supported one way or another.
Thanks,
--Beman