Quote:
It is needed in my development process. Otherwise when checking for syntax with -c option I will get error.It is not needed, you should use something like the following:
perl -c -I/path/to/admin/directory
Quote:
Data::Dumper is used for debugging in development phase. I don't care about GT::Dumper (which module is not standard in Perl, but Data::Dumpler is).You are missing the point. GT::Dumper isn't a standard perl module, but it will be installed on EVERY copy of Links SQL using your plugin and it is specific to Links SQL making it a more suitable choice.
Quote:
You are right, that they could be declared in one step. But usage of 13 "my" declarations does simply not matter in fact of the speed.
Yes it does.
Quote:
The optimization you suggest is unnecessary, since in the full execution time these 13 "my"-s are executed in less than 1%. Optimization is unnecessary for such small speed gain.Not only should speed optimizations be used when necessary (and where you even admit you could improve it) but also aesthetically and syntactically it would lead to an improvement.
Quote:
This does not mean any problems... It's my programming style, and I like using not instead of ! for easier readibility.
There is a difference in precedence between "not" and "!" - it's not a question of programmingstyle. I suggest you read the perldocs.
Quote:
Not incorrect. Both gives the same result, when comparing 2 integersAgain read the perldocs. It is incorrect usage, any perl programmer will confirm that.
Quote:
Same as above, with the addition, that there are NO number comparisions using 'eq'!!! You meant this code part?: $IN->param("step1") eq "1" .... also in html sourse: <INPUT TYPE="CHECKBOX" NAME="step1" VALUE="1">
All input parameters you get from the form are strings, so you statement is simply not true.
So it causes NO problems.
See my answer above.
Quote:
Paul, Yogi: you should try out this small exampleYou example doesn't prove anything as you aren't even using any blocks
Quote:
So your comment was NOT valid in CGI mode. Unfortunately under mod_perl the my() declaration usage on file level will not work if it's used under mod_perl. The mod_perl is the only reason to correct it, and avoid usage of my() declarations on file level.Sorry, I'm afraid you are incorrect again. It has nothing to do with mod_perl.
Quote:
Go ahead Paul, do hundreds of tests on my plugin, discover all the possible problems it has, and tell me all the problems!I didn't have to do hundreds of test...a quick scan through the code was enough to spot several potential problems.
If you choose not to correct them then only yourself and the people using your plugins will lose out in the end...I am just trying to assist you :)
I do think though you need to view the perldocs, especially regarding the use of my(0 and globals and also eq/ne/!=/==
