I think this is a much more flexible system than those suggested so far.
It seems to me that this approach
- lets the OS and the implementation deal with pathways that are valid
(taking into account locale and OS constraints).
- defines only that part of the location/directory tree/file system on
which perl6 programs operate, rather than having to understand the whole
environment in which software could run
- delegates to a module if perl6 is to be used to manage a specific
environment/OS
- offers more future proofing and portability than constraining what can
or cannot be in a pathname.
- allows users to configure via Policy.pm standard pathnames to
something non-standard for development and testing, leaving the software
itself unchanged.
Darren Duncan wrote:
<snip>
When you write a path, then rather than rooting it with "/", you
instead root it with "<doi>/".
Examples of "doi" can be:
fsroot - the root of the real file system, analogous to "/"
fscwd - the dir that was the fs CWD when Perl started up
docs - the dir that contains the usual files we want to work with
temp - the dir where we can put temporary files
home - the current user's home dir
mycwd - some other cwd-dir, which is virtual-changeable in Perl
To define a new doi at runtime, something like:
%DOI{'mycwd'} = %DOI{'fscwd'};
%DOI{'mycwd'} ~= 'subdir';
# later
my $fh = IO.open( 'mycwd/myfile.txt' );
For ease of use, we can still have vars like $*CWD, which might be an
alias for a doi with a specific name.
Note, please ignore my specific syntax for denoting Path objects. I
defer to other discussions and synopsis for those details, and mainly
what I'm trying to put across here is concepts.
My main point here is that we effectively can have multiple CWD in the
same Perl thread, and it shouldn't be too much trouble to make this
work well.
-- Darren Duncan
