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