Dave Whipp wrote:
"Rod Adams" <[EMAIL PROTECTED]> wrote in messageCase 1:
news:[EMAIL PROTECTED]
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 );
my $text is TextFile("/tmp/foo") is rw; my $text is TextFile("/tmp/foo") is const;
truncate Vs append would be infered from usage (assign => truncate). One
might be able to infer read Vs write in a similar way -- open the file based
on the first access; re-open it (behind the scenes) if we write it after
reading it.
So I wanted to do a read/write scan, so I create my TextFile, start reading in data, so the file is opened for reading. Then, I come to the part where I want to update something, so I do a write command. Suddenly the file has to be closed, and then re-opened for read and write. And all my buffers, file pointers and the like are reset, (though curable with very careful planning), leaving me in a bad spot. Better if I could just declare the file open for read and write at open time.
Case 2:
I meant to use some critical data file in read-only mode, and accidently use a write command somewhere I didn't mean to, and silently just clobbered /etc/passwd. Better if I could have just opened the file read only, and trigger an error on the write command.
What design philosophy would you envision TextFile taking to handle both these cases in a coherent fashion?
:excl would probably need to be an option, but is not sufficiently common to be agressively huffmanised: my $text is TextFile("foo.txt", :no_overwrite); my $text is TextFile("foo.txt") does no_overwrite;
ot that having wrapper classes for file handles is a bad idea, it justPossibly, but would need a hufmanized alias for common use. Possible just
doesn't relate to what I saw being discussed.
Oh, and "TextFile" should be spelled "IO::File::Text", IMHO.
"file":
s/file/open/ and we're back where we started.
my Str $text is file("foo.txt") does no_follow_symlink does no_create;
my $text = open("foo.txt" :no_follow_symlink :no_create);I don't think anyone (read: Larry) has declared exactly what the capabilities of the default file handle object are yet. It seems me that you could very well get what you want.
-- Rod Adams
