>>>>> "TM" == Tom Metro <[EMAIL PROTECTED]> writes:
TM> Your comments about doing "something that has life beyond the process TM> itself" and "incomplete run" seem a bit muddled and not consistent with TM> how eval behaves. Yes, as another poster pointed out, if you don't check TM> $@ after an eval, an error (compilation or otherwise) can go unnoticed, TM> if that's what you mean. it's easy enough to benchmark. just write a simple line of code like $x = 3 and also eval the same code string. the issue isn't the actual speed of eval but that we know it takes some real time and it isn't needed. so that is just cpu waste for lack of understanding of string eval. >> * efficiency: >> It causes the perl interpreter to be launched at run-time. TM> eval certainly isn't efficient, but it isn't quite as bad as you TM> imply. It's not as if a new process is forked and executed. As I TM> understand it, the penalty is in having to compile the eval'ed TM> code, but that compilation is done by the same interpreter process TM> running your script. it invokes a full interpreter, then it compiles the code and then it executes it. compare that to just executing the code which is what you get if you avoid string eval. this is also just the efficiency reason as opposed to the safety, bug causing, confusing, overkill and global hell reasons. my rule for symrefs and string eval apply here: only those who know when not to use string eval are allowed to use it. TM> I'm not sure how much overhead the block form of eval imposes, if TM> the eval'ed code doesn't vary at run time. it is compiled with all the other top level code at compile time. block eval has one purpose which is to catch dies. it was a major mistake (like with select) to name different things to the same name. so block eval isn't any slower than any other normal code. TM> It (more specifically the block form) seems to get used a lot TM> these days as a way to as a way to catch exceptions - a Perl TM> equivalent for try/catch. (Of course there is a module on CPAN TM> that implements try/catch, I assume using eval.) block eval is the only way to do exceptions in perl and it is just for its try/catch behavior with die. it has no relationship to string eval so even say the block form is slightly confusing as it implies a deeper connection. perl6 has it named properly as a CATCH block you declare inside a block. it will catch any exceptions inside that block and it has ways to filter out what exceptions it handles and which are passed up the call chain. so please tell this cow-orker that string eval is only to be used when it is the only or absolutely best solution. anything else means the problem can be and should be solved with normal compile time code. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
