This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: "James R. Allen II" <jamesrallen@att.com>
Newsgroups: comp.lang.perl.misc
Subject: Perl operators in variables
Date: Fri, 7 Feb 2003 17:53:39 -0500
Is it possible to use a variable with it's value being a valid Perl operator
in a conditional?
i.e.
my $operator = "=~";
if ($text $operator /[abc]/) {
do something...
}
===
Newsgroups: comp.lang.perl.misc
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Perl operators in variables
Date: Fri, 7 Feb 2003 17:23:44 -0600
James R. Allen II <jamesrallen@att.com> wrote:
> Is it possible to use a variable with it's value being a valid Perl operator
> in a conditional?
Why do you want to use a variable with it's value being a valid
Perl operator in a conditional?
There is likely a "better way", but we need to know what you
really need to accomplish before we can suggest one.
> i.e.
Surely you meant e.g. instead.
If it was i.e. it would not be variable.
> my $operator = "=~";
> if ($text $operator /[abc]/) {
"=~" and "!~" are the only two operators that take the pattern
match operator as an operand.
Maybe you just chose a poor example?
You could cobble something together with string eval() but
that could be very very dangerous...
===
From: Benjamin Goldberg <goldbb2@earthlink.net>
Newsgroups: comp.lang.perl.misc
Subject: Re: Perl operators in variables
Date: Fri, 07 Feb 2003 23:57:42 -0500
"James R. Allen II" wrote:
>
> Is it possible to use a variable with it's value being a valid Perl operator
> in a conditional?
>
> i.e.
> my $operator = "=~";
> if ($text $operator /[abc]/) {
> do something...
> }
my $operator = sub { $_[0] =~ $_[1] };
if( $operator->( $text, qr/[abc]/ ) ) {
...do something...
}
===
From: Malte Ubl <ubl@schaffhausen.de>
Newsgroups: comp.lang.perl.misc
Subject: Re: Perl operators in variables
Date: Sat, 08 Feb 2003 16:43:49 +0100
James R. Allen II wrote:
> Is it possible to use a variable with it's value being a valid Perl operator
> in a conditional?
>
> i.e.
> my $operator = "=~";
> if ($text $operator /[abc]/) {
> do something...
>
As always, use a hash:
my %binary_ops = (
"=~" => sub { $_[0] =~ $_[1] }
);
my $op = "=~";
if( $binary_ops{$op}->( "word", qr/\w/ ) ) {
print "works"
}
===
From: "Janek Schleicher" <bigj@kamelfreund.de>
Subject: Re: Perl operators in variables
Date: Sun, 09 Feb 2003 13:07:23 +0100
Uri Guttman wrote:
>>>>>> "TvP" == Tassilo v Parseval <tassilo.parseval@post.rwth-aachen.de> writes:
> TvP> Other than that I agree. The dislike of string-eval in this group
> TvP> sometimes seems a little too idiosyncratic.
>
> but abigail and you know how to apply string eval and where to use
> it. the real issue is that newbies tend to not know other ways and fall
> back on eval too quickly. sure it can look simpler and in some cases it
> actually is. but newbies using eval wantonly will lead them to using it
> where it is very dangerous. and they usually don't know safe areas from
> dangerous. so the group dislike of eval is a parental smack on the
> $BODY_PART telling the kiddie that they need to grow up more before
> being handed the keys to the perl car.
>
> too often kiddie uses of eval are easily solved with proper data
> structure, declaring variables in the right scope, etc. string eval's
> best use is for custom code generation which is rarely the goal when it
> is used. the rule should be that you use string eval if there is no
> other effective way to solve it. it is not the first solution in most
> cases.
Perhaps we should add when it is really recommendable to use eval in the FAQ.
It's not acceptable that
perldoc -q eval
doesn't founds documentation for a beginner.
(perldoc -f eval exists of course, but it explains how to use eval and not
when)
I sure lack a bit of phantasy, but myself uses eval usually in 4
situations.
eval {
BLOCK
}
if ($@) {
...
}
to catch errors
eval <<ROUTINE_OR_SIMILAR;
sub foo {
...
many statements depending on some configurations
(or other values, not changing while foo() is used)
but executed a lot
e.g. filters
to increase the efficeny
(sometimes even better than any optimized c program,
that doesn't use gcc and a system call)
}
ROUTINE_OR_SIMILAR
eval <<PROTOTYPE for qw/foo bar foobar/;
sub something_with_$_ {
my \$self = shift;
\$self->{$_}++; # or whatever
#
# or however
}
PROTOTYPE
to avoid doubling code, what's a real crime.
In perl 1-4 liners, just to have fun.
===
Newsgroups: comp.lang.perl.misc
Subject: Re: Perl operators in variables
From: Uri Guttman <uri@stemsystems.com>
Date: Sun, 09 Feb 2003 15:57:32 GMT
>>>>> "A" == Abigail <abigail@abigail.nl> writes:
A> In the hands of a newbie, eval isn't any more dangerous than vi. I
A> just don't buy it that it's ok to write a program and to compile
A> it, but that's oh so dangerous to do eval.
A> *eval is doing the same thing*
that isn't the case. writing a program is the primary level solution. using
eval is a secondary level solution. the fact that both compile code does
not equate them. we have all seen bad code and bad uses of eval. but
when a newbie uses eval for basic data manipulation (typically symref
type stuff like eval "\$$name = $value") they are just not doing it the
best way. this is not a relative evil thing or they can compile at any
time. it is bad code and they should be slapped.
A> || too often kiddie uses of eval are easily solved with proper data
A> || structure, declaring variables in the right scope, etc. string eval's
A> || best use is for custom code generation which is rarely the goal when it
A> || is used. the rule should be that you use string eval if there is no
A> || other effective way to solve it. it is not the first solution in most
A> || cases.
A> But it ain't a dogma. I use string eval, and `` in many cases where
A> it could have all been done with "real" Perl operations. Sometimes,
A> run time efficiency just doesn't matter.
it isn't a dogma for you and others who know what they are doing. the
key is always, was there a conscious decision behind this code? i trust
that your code won't use eval unless there was no other choice (japhs
and golf don't count :). a kiddie will hear about eval and use it as
their primary tool even though safer methods exist.
the key to the 'dogma' is to make sure newbies understand how dangerous
eval can be (and i don't mean security). and yes any code can be
dangerous but that is hand waving. we have seen too many newbies use
eval for no reason other than that is all they can do to solve
something. they need to be made aware it is not a good first cut answer.
what experts do and newbies do are different things. fire is good but
not for babies. sure a child can use a blowtorch or a lighter to start a
fire. which is safer for them and others? not all fire is the same and
not all compiling of code is the same.
===
Newsgroups: comp.lang.perl.misc
Subject: Re: Perl operators in variables
From: Uri Guttman <uri@stemsystems.com>
Date: Sun, 09 Feb 2003 16:02:54 GMT
>>>>> "JS" == Janek Schleicher <bigj@kamelfreund.de> writes:
JS> I sure lack a bit of phantasy, but myself uses eval usually in 4
JS> situations.
JS> eval {
JS> BLOCK
JS> }
JS> if ($@) {
JS> ...
JS> }
JS> to catch errors
that is block eval which has absolutey nothing to do with string
eval. block eval is not dangerous. string eval is.
JS> eval <<ROUTINE_OR_SIMILAR;
JS> sub foo {
JS> ...
JS> many statements depending on some configurations
JS> (or other values, not changing while foo() is used)
JS> but executed a lot
JS> e.g. filters
JS> to increase the efficeny
JS> (sometimes even better than any optimized c program,
JS> that doesn't use gcc and a system call)
JS> }
JS> ROUTINE_OR_SIMILAR
that is code generation on the fly which is something i already said is
string eval's primary purpose.
JS> eval <<PROTOTYPE for qw/foo bar foobar/;
JS> sub something_with_$_ {
JS> my \$self = shift;
JS> \$self->{$_}++; # or whatever
JS> #
JS> # or however
JS> }
JS> PROTOTYPE
that is better done as a closure which doesn't need eval. it is faster
and safer.
JS> In perl 1-4 liners, just to have fun.
i already exempted japhs from this 'dogma'. :)
===
From: Bart Lateur <bart.lateur@pandora.be>
Newsgroups: comp.lang.perl.misc
Subject: Re: Perl operators in variables
Date: Sun, 09 Feb 2003 16:09:37 GMT
Janek Schleicher wrote:
>I sure lack a bit of phantasy,
The danger of eval is in code like:
$\ = "\n";
while(<STDIN>) {
print eval $_;
print "Error: $@" if $@;
}
to get a simple interactive calculator. It's even a lot worse if this
happens in a CGI script instead of using the command line.
===
From: "J