On 2009-Aug-13, at 10:25 am, Hinrik Örn Sigurðsson wrote:
I've read a couple of posts about
file test operators, where some have suggested making filenames
special, either as a subtype of Str or something else entirely. That
way Str wouldn't have all these file test methods, which is good
because not all strings are valid filenames.
We should start thinking about the fundamental objects for doing IO as
IO-objects. They *have* names, but they aren't names, or strings, or
even filehandles (although they might *have* filehandles encapsulated
inside to do the actual work). A filename is merely a way to get at
the actual object, just as the string "2009/1/1" can be used to get a
Date object. A string, or a handle, or an inode, or some unique
filesystem spec number, or anything else you can get your hands on
should be fed to a constructor:
my $file = IO("/foo/bar/qux.txt");
Of course, this being P6, we can have some kind of "io" macro that
parses the single item after it:
my $file1 = io file://some/dir/some%20file; #
the quick way
my $file2 = IO.new(:protocol<file> :uri<foo/bar/a file.html>); #
the verbose way
The "file:" protocol might be assumed by default, but we could even
make the protocol keywords into IO-constructor macros:
my $x = file:///some/local/path; # an IO object
my $y = http://perl.org/index; # another one
(It might even be possible to get away without the protocol, if you're
willing to start all your regexes with an m and steal prefix / for the
io-builder:)
use io :default<file://>;
$x = /home/me/stuff.txt; # the lazy way =P
Then filetests and everything can belong to the IO class where they
belong, as well as eliminating the need for doublets like "eval" and
"evalfile".
There's a lot of scope for a nice, friendly, high-level IO view;
perhaps we need an IO-working group to assemble knowledge about what
is and isn't possible with different filesystems and design an
interface around it all.
-David
