develooper Front page | perl.perl6.language.regex | Postings from January 2001

Re: Exposing regexp engine & compiled regexp's

Thread Previous | Thread Next
From:
Rick Delaney
Date:
January 8, 2001 19:11
Subject:
Re: Exposing regexp engine & compiled regexp's
Message ID:
3A5A84F8.242B69B@home.com

Damian Conway wrote:
> 
> Branden wrote:
> 
>    > Then, what you proposed in RFC 93 through
>    >
>    >     sub { ... } =~ m/.../;
>    >
>    > could be handled by
>    >
>    >     my $mymatch = MyClassForMatchingFromFileHandles->new($myhandle);
>    >     $mymatch =~ m/.../;
> 
> This is an interesting alternative. The main problem is that matching
> against a blessed object already has a useful meaning in Perl: stringify
> the object (calling its overloaded stringification operator if possible)
> and match against the resulting string.

That may not be a problem.  In the absence of overloading of =~, the
object can be stringified (like now) but if =~ is overloaded then that
could take precedence.  Or, just make =~ behave the same as eq and use
fallback to get the current stringifying behaviour.  

The biggest problem is making =~ overloadable in the first place.  This
has a lot of potential but needn't replace your RFC:

    use overload "=~" => sub {
        my ($obj, $pat) = @_;
        my $coderef = $obj->{attr};
        $coderef =~ /$pat/;
    };


> My other problem with this approach is that it's relatively heavy. Let's
> take the example in the RFC and implement it both ways:
> 
>         # As the RFC proposes:
> 
>                 sub from_STDIN {
>                         $_[1] ? $fh->pushback($_[0]) : $fh->getn($_[0])
>                 }
> 
>                 \&from_STDIN =~ /pat/;
> 
>         # As Branden proposes:
> 
>                 package From_STDIN;
> 
>                 sub new       { bless $_[1], $_[0] }
> 
>                 sub MORE_DATA { $_[0]->getn($_[1]) }
>                 sub ON_FAIL   { $_[0]->pushback($_[1]) }
> 
>                 use overload "=~" => 1;
> 
>                 package main;
> 
>                 From_STDIN->new($fh) =~ /pat/;
> 
> Hmmmm. Potentially more flexible, but also much more ponderous.

I wouldn't say *much* more.  There is slightly more to do for a module
author (in object setup) but for the module user it is the difference
between:

    my $scalar = From_STDIN->new($fh);
    $scalar =~ /pat/;
and
    my $scalar = From_STDIN_closure($fh);
    $scalar =~ /pat/;

The overload technique can be made considerably less ponderous by
creating one class that behaves as your proposal.  Then those that like
it could just

    use RFC93 sub {
        $_[1] ? $fh->pushback($_[0]) : $fh->getn($_[0])
    };
    my $scalar = RFC93->new;
    $scalar =~ /pat/;

-- 
Rick Delaney
rick.delaney@home.com

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About