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


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:


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                           |

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-

Reply via email to