Very interesting idea. I decided to have a hack at it myself (code below). However, I stressed different aspects of the problem, so it's not exactly apples and apples, but a benchmark comparison would still be interesting. I predict that you incur significant overhead by having to deal with the regex record delimiter and the "read-ahead" buffer.

package Tie::Handle::MultiRec;

use Carp;

sub TIEHANDLE {
    my $pkg = shift;
    my $fn = shift;
    my $irs = shift || "\n";
    my $n = shift || 1;
    my $fh = *main::STDIN; # default
    $fn and open $fh, "<", $fn or croak "read $fn - $!\n";

    bless {
        readline => sub {
            local $/ = $irs;
            my $s;
            for ( 1 .. $n ) {
                eof($fh) and return $s;
                $s .= <$fh>;
            }
            $s
        },

        n => sub {
            @_ and $n = shift;
            $n
        },

        print => sub {
            for (@_) {
                /^N\w*=(\d+)/mi and $n = $1;
                /^I\w*="(.*?)"/msi and $irs = $1;
            }
        },
    }, $pkg;
}

sub READLINE {
    $_[0]{'readline'}->()
}

sub N {
    $_[0]{'n'}->($_[1])
}

sub PRINT {
    my $self = shift;
    $self->{'print'}->(@_);
}
[download]

• It will read from stdin if you supply a false filename.
• the methods are implemented as closures inside the new sub; this keeps me from having to continually assign between members of the object and lexical vars.
• You can set parameters of the object after initialization by calling the print method of the handle, as well as the usual methods of the tied object. I figured, this handle can't really do output, so use print as an out-of-band channel.

my $ctl = tie *FH, 'Tie::Handle::MultiRec', $0, "\n", 3;
my $n = 1;
while (<FH>) {
    print "Record $n:\n$_\n\n";
    $ctl->N(3+$n); # get more lines per read (the conventional way)
    print FH qq(irs=""); # switch to paragraph mode (using OOB)
    $n++;
}
[download]

Another possibility is to override local *CORE::GLOBAL::readline.

I'm not sure that the tied handle interface is the way to manage specialized data handling at the user's end. It seems more suited to hooking up a very different data structure to an I/O-centric application. Something like fetching DBI statement handle results as if they were lines from a CSV file.

It's no secret that I've slowly become a believer in tie. As I said somewhere else, tied interfaces are slower because they are doing something. Presumably, it should be something worth doing - something that would otherwise have to be done explicitly, in multiple places.

As a matter of taste, I'm not sure that should encompass new conventions which modify standard perl semantics. We're accustomed to the diamond op returning a single $/-delimited line in scalar context, and the list of all lines in array context. To produce a tied handle interface that alters those semantics seems backwards to me.

In Tie::Constrained, I found that tie provided a wedge into assignment that is unavailable with any other Perl construct. I notice that there is a similar opportunity in tied handles. A "file" handle can be produced which fails with a preset system error, on a particular kind of operation. That could be valuable for testing. Imagine being able to test for correct error handling when an operation on STDERR returns EPERM or ENOSPC.

It's a well-known wart on Perl that global print is not overridable (that's why Fatal doesn't work for print). With a tied interface, we have the PRINT method. That is another unique wedge into an otherwise immutable bit of Perl.

Whether I like this particular tied handle class or not, this is a very interesting topic. I'm glad you brought it up.

my $ctrl = tie *fh, 'Tie::File::Custom', 'num.dat'
    or die "Unable to tie : $!";

$ctrl->LINES( 2  ); # Return 2 lines at a time
$ctrl->BUFF( 100 ); # Read 100 bytes at a time since we expect sh
[download]

Mugatu,
Right. I offer both approaches in Tie::Hash::Sorted as well as passing the arguments in the constructor. As you can see, I don't much care for the alternative either. Thanks though!

Cheers - L~R