Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

RE (2): Filehandle Filter

by tilly (Archbishop)
on Aug 11, 2000 at 05:23 UTC ( [id://27432] : note . print w/replies, xml ) Need Help??

in reply to RE: Filehandle Filter
in thread Filehandle Filter

Well since you beat me to the original, here is an implementation that by default does what btrott's original display did, but can do anything you want. For giggles and grins I have implemented new and PRINTF using two different idioms:
package Filter::Handle; use strict; use Carp; sub PRINT { my $self = shift; my $fh = $self->{fh}; print $fh $self->{disp}->(@_); } sub PRINTF { my $self = shift; @_ = ($self, sprintf(shift, @_)); goto &PRINT; } sub TIEHANDLE { my $class = shift; my $fh = shift or croak("Need a filehandle to tie to."); my $disp = shift || sub { my ($file, $line) = (caller(1))[1,2]; sprintf("%s:%d - %s\n", $file, $line, "@_"); }; return bless ({fh => $fh, disp => $disp}, $class); } # An OO interface for free! :-) *new = *TIEHANDLE; *print = *PRINT; *printf = *PRINTF; 1;
(And yes, chip this is for you because of RE: RE: Shot myself in the foot with a pos. Who said that goto was useless? :-)

Chip made 2 very good style suggestions on the anon sub, and I am glad to have made both of them.

In addition to the suggestions chip made, I had removed my other return. At the time I wondered if I should, and tye's misgivings confirmed my misgivings. It belongs, it really does.

Note that this could be more compact still. For instance the anon sub could be made even shorter by removing the temporary variable. But that would not optimize my ability to understand my code. :-)

OK, I got tired of the temporary variable in PRINTF that was clearly not needed. I have not (yet) convinced myself that it would be a good thing to drop the two in the anon sub. I also added a print and printf functions as syntactic sugar to make the OO interface a bit nicer. Oh, and I added a comment. :-)

For those who do not understand tie, this package has two distinct interfaces. The OO one works like this:

my $out = new Filter::Handle(\*STDOUT); $out->print("Hello world\n"); $out->printf("%s %s\n", "Hello", "world");
The tied interface like this:
tie (*OUT, 'Filter::Handle', \*STDOUT); select(OUT); print "Hello world\n"; printf ("%s %s\n", "Hello", "world");
The apparently shocking similarity in the implementations drives home the fact that tie is nothing more than syntactic sugar to allow you to think about an object which happens to provide the right methods as a native Perl datatype. :-)

BTW my absolutely favorite part of this code is the DESTROY method. Stuff like that is what makes Perl great! :-)

Replies are listed 'Best First'.
RE: RE (2): Filehandle Filter
by chip (Curate) on Aug 11, 2000 at 05:38 UTC
    I love it! :-)

    My favorite bit is *new = *TIEHANDLE. That's just inspired.

    I have to deduct a style point for unnecessary use of the return operator, and the explicit call of join when "@_" would be both shorter and clearer (IMO).

    But to repeat: This is a neat hack. Thanks.

        -- Chip Salzenberg, Free-Floating Agent of Chaos

      Agreed on both points, though I had to ask what you meant partially b/c I often use "" to offset snippets of code. I will make both changes. :-)

      I disagree strongly about avoiding return. That practice was desirable on old versions of Perl for speed. However, its explicit use makes the code easier to read, especially since you can't declare whether your sub is supposed to return a value or if it just happens to return a value because of the last statement executed.

              - tye (but my friends call me "Tye")
        When return forces you to choose between having the sub be 2 lines or running over 80 char, I think chip is right. If you are comfortable with anon subs, you probably have no problem with implicit return values.

        Most of the time I use return, but in this case I stripped it out. And since the entire point of the code was to show me throwing around a ton of constructs, with each one serving to make the code shorter and clearer to a true expert (though not to co-workers), I had no hesitation in pulling out my return at the end of TIEHANDLE. Which I possibly shouldn't have done.

        Oh well.