Re^4: Hacking Perl Code

[Discipulus]

Dear LanX,
i only meant, as explained in the update of the original post that my solution only executes any BEGIN block and no more, while with perl -c -d:TraceUse script.pl all the BEGIN UNITCHECK CHECK blocks are executed.
I was wrong (so thanks for your question), because my code also executes any END blocks and even other UNITCHECK already present, because those blocks run LIFO.
Here some code to demonstrate the concept. With a script called test_of_executed_code.pl as follow:

BEGIN{print qq(1-begin\n)};
UNITCHECK {print qq(2-unitcheck\n)};
CHECK {print qq(3-check\n)};
INIT {print qq(4-init\n)};
  print qq(5-main\n);
END{print qq(6-end\n)};

You can now compare the two solutions:

some_win>perl -c -d:TraceUse test_of_executed_code.pl
1-begin
2-unitcheck
3-check
Modules used from test_of_executed_code.pl:
test_of_executed_code.pl syntax OK

while with my script you'll see:

some_win>perl used_modules.pl test_of_executed_code.pl
1-begin
2-unitcheck
strict               1.04
warnings             1.12
6-end

The only way i found to prevent the END blocks to be executed is to change, in the UNITCHECK part of the original script, exit; with an ugly exec qq(perl -e "exit"); that produces:

some_win>perl used_modules.pl test_of_executed_code.pl
1-begin
2-unitcheck
strict               1.04
warnings             1.12

But, considering the LIFO aptitude of the UNITCHECK blocks, i can do it better and change eval $begin.$content; with eval $content.$begin; producing:

some_win>perl used_modules.pl test_of_executed_code.pl
1-begin
strict               1.04
warnings             1.12

Thanks for the opportunity to learn something more.
L*

[LanX]

Well OK I see, you exit before CHECKs are executed and -c does all UNITCHECKs and CHECKs.

But please be aware that any BEGIN and UNITCHECK within a required module is executed, so you are only disabling CHECK and other UNITCHECKS on the top level script.

As I said, IMHO does Devel::TraceUse have the more flexible and extendable approach, because it catches all includes before they are done (and immediately printing a nested tree output)

You are parsing the (hopefully unmanipulated) entries from %INC at the top-level.

Both approaches have their pro and cons... :)

update

your approach is not much different from a source filter, so if you consider to release it as a use-able module you could implement it that way. But please be aware that both approaches have to deal with trailing __DATA__ and __END__ sections when appending (instead of prepending) a UNITCHECK.

[Discipulus]

Thanks again LanX, you are becoming my teacher in elenctic method.. ;=)

My attempt is only to show something i discovered and that fascinate me, as everytime with Perl. In a 'reinvent the wheel' style as a way to learn. As you can guess from my signature i would use Devel::TraceUse in a real project. Your comment are correct.

I do not think to release something, may be usefull for me to investigate what a source filter is.

When i was on my motorbike, 20 minutes after last post, i thought to the __DATA__ and __END__ side effect.

See you at next question, i hope.

L*