note
ambrus
<P>
Couldn't one write ACME::Include based on source filters
instead of the DB way you gave above?
<P>
Source filters are a bad idea in general, but note that
this one does not attempt to parse perl code,
so it can not be fooled by wierd-looking perl code like
some source filters can be.
I still don't say that soing such things would be a good idea,
but it might be cleaner that the DB hack.
<P>
Here's my example, which just a quick draft,
does not handle line numbers etc.
<P>
<B>Filter/Include.pm<B> is
<code>
package Filter::Include;
use warnings; use strict;
use Filter::Util::Call;
sub import
{
@_==2 or die qq{usage: use Filter::Include "filename"};
open my $f, "<", $_[1] or die qq{cannot open include file "$_[1]": $!};
read $f, my $d, -s $f or die qq{cannot read file "$_[1]": $!};
filter_add(sub {
$_ = $d;
filter_del();
1;
});
}
1;
__END__
</code>
<P>
<B>first</b> is:
<code>
#!perl -w
use warnings; use strict;
my(@a, @b);
@a = (
1, 2,
do{ use Filter::Include "./second"; },
7, 8);
print "a(@a) b(@b)\n";
__END__
</code>
<P>
and <b>second</b> which has to be in the current dir when first is run:
<code>
3, 4); @b = (5, 6,
</code>
<P>
Then, <code>perl first</code> prints <code>a(1 2 3 4) b(5 6 7 8)</code>
393426
393426