From: Kripa Sundar <[EMAIL PROTECTED]>
Date: Mon, 15 Aug 2005 14:04:48 -0400
Dear Ben,
> > > another bad point about eval is that it can access and modify lexicals
> > > and globals anywhere in the code. so that can lead to action at a
> > > distance and very hard to find bugs.
> > [...]
> I'm not sure if this is what is referred to, but it applies.
>
> If this is dynamic code where the string to be evaled is
> passed in from elsewhere, then one problem is that you
> might wind up picking up lexicals in the scope of the
> eval, and being unable to pick up lexicals in the scope
> where you tried to create the eval. Closures would get
> this right.
Amen.
> Ruby solves this problem by giving you a number of
> variations on eval, one of which evals things in the
> context of your caller. Still not perfectly general, but
> much more likely to be right in this instance.
And not as robust as calling a closure would be.
Do you mean examples like below?
----------------------\/--------BEGIN---------\/----------------------
% perl -le 'my $x = 7; my $str = q{print ++$x}; {my $x = 11; eval $str}'
12
%
----------------------/\---------END----------/\----------------------
IMHO the current behaviour is intuitive. And I certainly don't
see "action at a distance". The person who thinks that the '$x' inside
$str is referring to the currently visible $x (value 7) is simply
mistaken . . .
True, but that just means that the scope of $x in the string depends on
where you eval it; if evaluated in multiple contexts, it might have
different meanings in each of those contexts. Contrast this to a
lexical sub, which has a single fixed meaning that can be determined by
expecting the definition context only.
Consider the following variation on your example:
[EMAIL PROTECTED]> perl -le 'my $x = 7; my $sub = sub {print ++$x}; {my
$x = 11; &$sub; }'
8
[EMAIL PROTECTED]>
So the behavior of eval is counterintuitive if you are expecting lexical
scoping. (Which you should be, given all those "my" variables.)
I'm sure this is what Ben meant by "Closures would get this right."
(Sorry if I'm stealing your thunder, Ben.)
-- Bob Rogers
http://rgrjr.dyndns.org/
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
