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


Reply via email to