"Rod Adams" <[EMAIL PROTECTED]> wrote in message
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.
: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;
> 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.
Possibly, but would need a hufmanized alias for common use. Possible just
"file":
my Str $text is file("foo.txt") does no_follow_symlink does no_create;
Do we have an antonym for C<does>?
Dave.
