Troels Liebe Bentsen wrote:
> Hey,
>
> Just joined the list, and I too have been thinking about a good path literal
> for Perl 6. Nice to see so many other people are thinking the same :).
Welcome to the list!
> Not knowing where to start in this long thread, I will instead try to show how
> I would like a path literal to work.
A well-considered proposal, and one with which I mostly agree. Some thoughts:
> The default p{} should only allow "/" as separator and should not allow
> characters that won't work on modern Windows and Unix like \ / ? % * : | " >
> <,
> etc. The reason for this is that portable Path's should be the default and if
> you really need platform specific behavior it should be shown in the code.
I note that you explicitly included * and ? in the list of forbidden
characters; I take it, then, that you're not in favor of Path as a
glob-based pattern-matching utility? E.g.:
my Path $path;
...
unless $path ~~ p<astro*> { say "the file doesn't begin with 'astro'". }
Admittedly, this particular example _could_ be accomplished through
the use of a regex; but there _are_ cases where the use of wildcard
characters would be easier than the series of equivalent tests that
Perl would otherwise have to perform in order to achieve the same
result. Hmm... maybe we need something analogous to q vs. qq; that
is:
p<astro*> #`{ syntax error: '*' is not a valid filename character. }
pp<astro*> #`{ returns an object that is used for Path
pattern-matching; perhaps Pathglob or somesuch? }
> We should allow windows style paths so converting and maintaining code on this
> platform is not a pain.
:
> For Unix specific behavior we should have a p:unix{} literal, here the only
> limit are what is defined by locale.
:
> And for people where this is a problem p:bin{} can be used as no checking is
> done here.
:
> Old style Mac paths could also be supported where the : is used as separator.
:
> Or old dos paths where 8 char limits and all the old dos stuff apply.
Hear, hear. Note that these are all mutually exclusive, which
suggests that the proper format ought to be something like:
my Path $path = p:format<win>{C:\Program Files}
However, I have no problem with the idea that :win is short for
:format<win>; the feature here is brevity.
> Urls could also be support with:
>
> my Path $path = p:url{file:///home/test.file}
I would be very careful here, in that I wouldn't want to open the can
of worms inherent in non-file protocols (e.g., ftp, http, gopher,
mail), or even in file protocols with hosts other than localhost.
> ** Path Object like File::Spec, etc. just nicer **
:
> ** Comparing Paths should do the right thing **
Agreed on all counts.
> ** Utility functions **
>
> Path in itself knows nothing about the filesystem and files but might have a
> peek in $*CWD to do some path logic. Except for that a number of File related
> functions might be available to make it easy to open and slurp a file a Path
> points to.
>
> my File $file = p{/etc/passwd}.open;
> if($file.type ~~ 'text/plain') {
> say "looks like a password file";
> }
>
> my @passwd = p{/etc/passwd}.lines;
>
>
> if(p{/etc/passwd}.exists) {
> say "passwd file exists";
> }
As soon as you allow methods such as .exists, it undermines your claim
that Path knows nothing about the filesystem or files. IMHO, you
should still include such methods.
--
Jonathan "Dataweaver" Lang
