I was thinking about the discussions about the "open" function, and of the
capabilities of "string"s.
Given that we'll have things like $str.bytes, etc. It doesn't seem a stretch
to suggest that we could also have $str.lines. Once we have that, and also a
level of pervasive laziness (lazy evaluation), it seems to me that we don't
really need user-visible file handles for most of the common operations on
files.
Imagine:
my $text is TextFile("/tmp/foo.txt");
for $text.lines {
...
}
The for loop is equivalent to the old "while(<FH>)" construct, but is more
general in the sense that it applies to any test-like thing, not just
file-handles. It also makes it easy to see how a use would apply a grammar
to the contents of a file.
Not all files are TextFiles, of course. We might have XML files, RawBinary
files, etc. If we can think in terms of tying, then we can use all this
things without ever touching a file handle.
Writing a file is similarly encapsulated:
my $text is TextFile("/tmp/bar");
$text = "hello"; # writes, truncates
$text ~= ", world\n"; # appends
$text.print "again\n"; # for old-times sake
Another use of filehandles for interactive communication over (e.g.) a
socket. Interactive communication can be thought of as message passing --
which perhaps should be unified under a general mechanism for sending
messages between threads/process/etc. A "producer" sends messages to a
"consumer", and thus has an object (proxy/handle) that represents that
consumer. The fact that the implementation is a "File Handle" is not
something that a user needs to worry about (usually).
I guess what I'm saying is that if we can make tying the standard idiom,
then we can relax you huffmanization worries for things like the "open"
function.
Dave.
