Dave Whipp wrote:

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 {
   ...
 }

<snip>

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.


Uhm, my impression was that most of the "huffmanization" discussion was centered around declaring a file handle to be read only, write only, read-write, exclusive, etc. Masking the file handle with what basically amounts to a file handle subclass like you describe will still need to allow the user to specify all those attributes.

So you would still need to allow:
my $text is TextFile("/tmp/foo.txt" :rw );
my $text is TextFile("/tmp/foo.txt" :excl );

Not that having wrapper classes for file handles is a bad idea, it just doesn't relate to what I saw being discussed.
Oh, and "TextFile" should be spelled "IO::File::Text", IMHO.


-- Rod Adams

Reply via email to