Paul wrote:

   > > Given this level of complexity, it's perhaps not surprising that source
   > > code filtering is not commonly used.
   > 
   > Whilst I don't have any problems with you module, I think you are
   > overstating the complexity of the existing situation. This should be all
   > that is needed to create your filter.
   > 
   >     package BANG;
   > 
   >     use Filter::Util::Call ;
   > 
   >     sub import
   >     {
   >       filter_add( sub {
   >         my ($status);
   >         s/BANG\s+/die 'BANG' if \$BANG/g

Should be:

             s/BANG\s+BANG/die 'BANG' if \$BANG/g

   >             if ($status = filter_read()) > 0 ;
   >         $status ;
   >       })
   >     }

No. That's my point. I want to match BANG followed by maximal whitespace
followed by another BANG. But a line-by-line filter fails dismally if that
maximal whitespace contains a newline.

Admittedly this particular example is contrived for effect, but I have
now used your excellent module in numerous projects when constructs *can*
cross newline boundaries and it's always painful to do (hence the new
module). In fact, I would claim that filtering constructs across
newline boundaries is the *norm*, since newlines are just whitespace most
places in Perl.


   > > This RFC proposes that a new standard module -- Filter.pm -- be
   > > provide to vastly simplify the task of source code filtering,
   > > at least in common cases.
   > 
   > Can I suggest you feed data a line at a time rather than the series
   > of lines as you do right now. That makes it work like the existing
   > filters.

No. That's the point. Line-by-line processing is not adequate in the general
(and common) case.

 
   > I'm not sure Filter is the best name for this. How about Filter::Transform
   > or Filter::Simple?

Filter::Simple is much better. Thanks. :-)

Damian

Reply via email to