On Sat, Aug 15, 2009 at 7:17 AM, Timothy S. Nelson<wayl...@wayland.id.au> wrote:
> On Sat, 15 Aug 2009, Austin Hastings wrote:
>
>> This whole thread seems oriented around two points:
>>
>> 1. Strings should not carry the burden of umpty-ump filesystem checking
>> methods.
>>
>> 2. It should be possible to specify a filesystem entity using something
>> nearly indistinguishable from standard string syntax.
>>
>> I agree with the first, but the relentless pursuit of the second seems to
>> have gone beyond the point of useful speculation.
>>
>> What's wrong with
>>
>> File('C:\Windows')
>>
>> or Path() or Dir() or SpecialDevice()?
>>
>> Not to get all Cozens-y or anything, but chasing after ways to jam some
>> cute string-like overloading into the syntax so that we can pull out the
>> other overloading (which at least had the virtue of simplicity) seems
>> pointless.
>>
>> The File::* functionality is probably going to be one of the very early p6
>> modules, and it is probably going to be in core. If that's true, why not
>> allocate some really short names, ideally with 0 colons in them, and use
>> them to spell out what's being done?
>
> S32/IO already specifies all these things as living in the IO
> namespace. That could be changed, of course.
>
>> Neither q:io:qq:{.} nor qq:io{.} really stand out at excellent ways to say
>
> q:io{.} would be the normal case, unless you want variable
> interpolation or the like. And it would be possible to come up with shorter
> versions (someone suggested qf).
>
>> "this is a path", or directory, or file, or whatever. If it's
>> plug-in-able, I'd take qq:file{.} or qq:dir{.} or qq:path{.}, but I'd rather
>> see C< File q{.} >.
>
> I'm not particularly attached to :io if we can think of something
> better. These things often have a short name and a long name. I'm against
> "file" because the IO::File object models what is inside the file (ie.
> open/read/write/close/etc), whereas the
> IO::FSNode/IO::FileNode/IO::DirectoryNode/IO::LinkNode objects model stuff
> on the outside of the file. It's things of this second type that I'm
> recommending that we return here. We could change the names of the objects
> of course, but I'm keen on keeping the class that does stuff to the inside
> of the file separate from the class that does stuff to the outside of the
> file. "Path" might be a good alternative in my mind.
IOW, your "outside the file" stuff is whatever can be done without
having to open the file, and your "inside the file" is whatever only
makes sense once the file has been opened. Correct? If so, could you
give some examples of how such a distinction could be beneficial, or
of how the lack of such a distinction is problematic?
> Anyway, back to the :io name. An alternative might be to have the
> short name be :p and the long name be :path. That would mean that we could
> do:
>
> q:p{.}
Isn't there something in the spec that indicates that qq is merely
shorthand for q:qq? That is, it's possible to bundle a bunch of quote
adverbs together under a special quote name. If so, you might say
that q:path and q:p are "longhand" for path:
path{.} # same as q:p{.}
And yes, 'path' is longer that 'q:p' - but only by one character; and
it's considerably more legible. As well, this is more in keeping with
what's really going on here: path{.} would be no more a string than
m{.} or rx{.} are. In fact, having q, Q, or qq involved at all
strikes me as wrong, since those three are specifically for generating
strings.
Also note the following:
"string" # same as qq[string]
'string' # same as q[string]
/pattern/ # same as m[pattern]?
The ultimate in "path literals" would be to establish a similar
"default delimiter". For example, what if the backtick were pressed
into service for this purpose? (No, I'm not actually suggesting this;
at the very least, there would be p5 false-compatibility issues
involved. This is strictly illustrative.)
`path` # same as path[path]
`path`.e # does that filename exist? Returns boolean.
`path`.size # how big is the file? Returns number.
`path`.open # Returns new file handle.
> That's a fair bit shorter than Path(q{.}). Hmm. Let's compare some
> code samples:
>
> if (q:p'/path/to/file' ~~ :r) {
> say "Readable\n";
> }
> if (Path('/path/to/file') ~~ :r) {
> say "Readable\n";
> }
if (path'/path/to/file'.r) {
say "Readable";
}
if (`/path/to/file`.r) {
say "Readable";
}
> $fobj = new IO::File(FSNode => q:p'/path/to/file');
> $fobj = new IO::File(FSNode => Path('/path/to/file'));
$fobj = path[/path/to/file].open;
$fobj = `/path/to/file`.open;
> I used single quotes for the Path() things because I think that's
> what people would probably do.
>
> Now, say we want to use backslashes.
>
> if (Q :p {C:\Windows\file} ~~ :r) {
> say "Readable\n";
> }
> if (Path(Q {C:\Windows\file}) ~~ :r) {
> say "Readable\n";
> }
if (path:win[C:\Windows\file].r) {
say "Readable";
}
> Anyway, we have possibilities. Further thoughts anyone?
As illustrated above, I think that the main benefits of having a path
literal would be that you _can_ handle file tests as methods of a path
(as opposed to making them string methods), and that a path literal
doesn't have to follow the same parsing rules that strings do. In
fact, path literals may be more pattern-like than string-like, when
and if you start taking wildcard characters into account:
if $file ~~ path[./*.txt] {
say "$file is a text file in the current working directory."
}
if $file ~~ `./*.txt` {
say "$file is a text file in the current working directory."
}
--
Jonathan "Dataweaver" Lang
