On Mon, Aug 17, 2009 at 23:11, Jon Lang<datawea...@gmail.com> wrote:
>> 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? }
Glob's are special and should properly have it's own sub format, the problem of
including * and ? in Path's is that on Unix this is a allowed file system name.
Q:glob{} and g{} might be nice.
Buy then again as * and ? is disallowed for the default portable p{}, using any
of these might make it return a PathGlob instead. But I think an glob
interpolating pp{} might be the best solution, so the default p{} is strict and
returns and error.
my Path $path = p{file.txt};
my PathGlob $pathglob = pp{*.txt};
Allowing code like this:
for(pp{*.txt}.open -> $file) {
my @lines = $file.lines;
}
>> 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.
You are properly right, but then again if it's not up to Path to actual know
how to open or work with the file/url. It would only have to know the rules for
how urls work not how to open them. In it's basic form Path should not be able
to do any IO.
But I'm not too sure URL's belong in Path.
>> ** 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 file system or files. IMHO, you
> should still include such methods.
My idea with the utility functions are that they are merely wrappers or pretty
syntax for using the build in IO call. So if fx. url paths where included in
the spec, most of these functions would be provided by libraries
handling the IO.
How this can be done in a nice OO way, I don't know, but I'm sure people a lot
smarter than me can figure that out.
Regards Troels
