IMO, the DB hack is a cleaner solution, because it is faster, uses a
documented feature ...
I don't think any of them would be much faster than the other.
The source filter is documented too.
and has clean syntax for using it. To achieve such clean syntax with a source filter, you need to write a complex regex.
It's not that simple.
The difference is that the code I gave above does the include
in compile time, and its syntax is use Filter::Include "file"
(the do is not needed when including complete statements).
The DB way includes the code at run-time, that's why it's
possible to use a simple subroutine include "file"
is possible. While it is indeed not possible to make
my solution work with such a simple syntax, without
actually interpreting the code (incidentally that's what the actual
Filter::Include cpan module does);
if you wanted to modify the DB solution so that it includes
the code in compile time (which can be a difference
in semantics, depending on what the include file contains),
you'll have to use a use or BEGIN
syntax too, or try to parse the code.
Besides that, source filters don't work everywhere (like in eval)...
That's true. More generally, source filters can be used
only at compile-time, not runtime. Also, source filters
can not be used from command line (-e) it seems.
and I
really think the included file should by itself be syntactically correct.
Including code is bad, but including partitial expressions is, IMHO, even
worse.
True. I just wanted to show that this is really including the file.
Finally let me note that some include facility is already
built in perl: the -P switch. If the file third
contains
#!perl -w
use warnings; use strict;
my(@a, @b);
@a = (
1, 2,
#include "./second"
7, 8);
print "a(@a) b(@b)\n";
__END__
and you run it with perl -P third, you get the
same results.
Of course, perlrun warns you that there are lots of problems
with the -P switch.
| [reply]
[d/l]
[select] |
Finally let me note that some include facility is already built in perl: the -P switch.
The -P switch is built in, but its functionality is all but. It depends on an external utility and execs sh, then perl and then cc. It's not only a very dangerous construct, but also a very inefficient one :)
| [reply] |
