>>>>> "KS" == Kripa Sundar <[EMAIL PROTECTED]> writes:
KS> Dear Ben, Tim and others,
KS> I've been learning a lot from this entire thread. Thanks to all the
KS> responders.
i just want to reiterate my view on string eval (and symrefs). they are
powerful tools that are needed to solve a certain class of
problems. they rarely are the best solution and must be used only when
they give you a distinct advantage when used. most problems that newbies
think need them, do not. they are dangerous in that data will be
affecting code and that is hard to debug, verify, etc. string eval will
delay any compilation to run time vs compile time so you can lose out on
finding syntax errors until much later. generating code to be evaled is
not easy and it is frought with trickiness. if you code up bad data, you
could unexpectedly affect any global in the system and that is very hard
to track down.
damian's perl best practices has a rule/section on not using string
eval. it isn't as strongly worded as my rule (see below) but it offers
some good reasons, notably the delayed syntax checking point. damian
prefers closures or anon subs if you need to pass in user code.
so my rule again (and kripa, tell your cow-orker this one) is:
you should not use string eval (or symrefs) unless you know when not to
use them. they are not the tool of first resort but a tool of last
resort.
and since i brought up symrefs, i will expound on why they are bad
too. first off, the symbol table is just a specialized hash tree with
different syntax. so doing general purpose data munging in the symtree
is a total waste since you can always do it in normal data trees. and
normal trees offer isolation (you can pass subtrees around and nothing
but that tree will get munged) and lexical scoping for both safety and
garbage collection (lexical trees will get reclaimed with no more refs
point to it, symref trees are global and never collected unless you do
major explicit work). as with string eval, if the data is bad, you can
accidentally refer to distant global vars and that is a nasty bug to
fix. the rule here is that you only use symrefs when you are munging the
symbol table. this is needed with exporting, inserting methods on the
fly (e.g. AUTOLOAD or pregenerating accessors), etc. those are not data
munging but actual symtable munging.
kripa, ask your cow-orker to defend his use of string eval. as in why it
is needed vs solving the problem in some other safer and more
understandable way. ask him if it is faster, easier to understand, makes
cleaner code, safer, etc.
here is one small use of string eval which makes for cleaner code:
if you are loading a module on the fly (its class name is generated or
comes from a config file), then this doesn't work if all you have is
Foo::Bar in $class.
require $class ;
require with an expression needs a path to the module and that means
that :: needs to be converted to the proper separator for the OS
(File::Spec can do that for you) and .pm must be appended as well. so
this would take a few lines of code (which could be wrapped in a sub to
make it cleaner). but it can be done in one clear line with string eval:
eval "require $class" ;
and check the result and $@ for errors. and put in a comment that you
know what you are doing. :)
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
