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.
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{.}
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";
}
$fobj = new IO::File(FSNode => q:p'/path/to/file');
$fobj = new IO::File(FSNode => Path('/path/to/file'));
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";
}
Ok, so they're comparable. I've used curlies here just because I
thought it was a good idea :).
Anyway, we have possibilities. Further thoughts anyone?
:)
---------------------------------------------------------------------
| Name: Tim Nelson | Because the Creator is, |
| E-mail: wayl...@wayland.id.au | I am |
---------------------------------------------------------------------
----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----
