On Wed, 2 Aug 2000, Nathan Wiger wrote:
> Tom Christiansen wrote:
> >
> > >Not sure I agree with that. I think one point of confusion / perceived
> > >difference between filehandles, open(), and basically every other
> > >builtin is that all the others *return* what you want.
> >
> > tie and bless and chop and chomp also all act upon their argument(s).
> > Just to name a few. bless has the nice side effect of returning it,
> > too, but the rest are probably subject to your confusion issue.
>
> Now, one could argue the following. You could spruce up open() so it
> acted more like tie. I could see this adding a lot of functionality:
>
> $object = open($fh, "<$filename") or die;
>
> You could ignore the $object just like with tie (maybe in 90% of your
> calls), but if you chose to use it you would have direct access to, say:
>
> $object->autoflush;
> $object->untaint;
>
> Thus, you have the "same old open()" for those who like it, but with the
> added functionality of generating a FileHandle-esque object.
>
I think you'll find that the autovivified $fh in the above open() already
acts as an object.
open my $fh, "<test.dat";
$fh->autoflush;
my $line = $fh->getline;
works fine for me on perl5.6.0 so long as IO::Handle has been "use"d. In
fact, if IO::Handle is not avialable perl5.6.0 currently complains:
Can't locate object method "autoflush" via package "IO::Handle" at ./test.pl line 5.
It seems that this issue is definitely worth a quick RFC - something
like "proposal to return filehandles from open/opendir rather than supply
as arguments". Whether this should be extended to chomp et al is, I
believe, another issue since they are modifying the contents of a variable
whereas open is overwriting.
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
