Re^2: The safety of string eval and block eval.

I'm not sure string eval is needed to create a generic interator, I was able to reproduce all your examples with just anonymous subs and some @_ juggling:

#!/usr/bin/perl
use warnings;
use strict;
use feature qw{ say };

sub create_iter {
     my ($code_ref, @rest) = @_;
     sub { $code_ref->(@rest) }
}

my $iter = create_iter(sub { $_[0] += 2 }, 0);
say $iter->() for 1 .. 5;

my $fibo = create_iter(sub { @_[0, 1] = ($_[1], $_[0] + $_[1]); $_[1] 
+}, 1, 1);
say $fibo->() for 1 .. 7;

my $fact = create_iter(sub { $_[1] *= ++$_[0] }, 1, 1);
say $fact->() for 1 .. 5;
[download]

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Comment on Re^2: The safety of string eval and block eval. Select or Download Code

Replies are listed 'Best First'.
Re^3: The safety of string eval and block eval. by Laurent_R (Canon) on Aug 15, 2016 at 11:13 UTC
Yes choroba, you're right, thanks a lot for your examples. It seems it can be done playing with `@_`, at least for those examples. Either I was simply not able to find the right syntax when I was playing with these things a couple of years ago, or my actual use cases were more complicated than the simple examples I gave in my previous post. I'd have to go back to what I was doing at the time to figure that out, but I do not have these things available with me today. My gut feeling, though, is that I probably was simply not able to find the right syntax.	[reply] [d/l]
Re^4: The safety of string eval and block eval. by afoken (Chancellor) on Aug 15, 2016 at 19:51 UTC
As a very generic rule of thumb: If you think that you need a string eval, you are doing it wrong. There are very few good reasons for using a string eval, and even fewer if the string eval has to work on input controlled by the user. use, require, and the rare do FILENAME, are of course string `eval`s behind the scenes, and they are useful and the proper way to load perl code from files. In very rare cases, perl functions have to be generated from data at run time, and at that point, a string `eval` is actually the best way to solve the problem. But for tasks like parsing configuration files, "variable variable names", constructing variables at run-time, reading data back from stored files (e.g. from Data::Dumper), string `eval` is the wrong way. Configuration files are better stored as INI files, JSON or XML (all readable and all without executable code). "Variable variable names" and variables constructed at runtime are better implemented via arrays, hashes, or (worst case) symbol table manipulation. And data is better stored using JSON, XML, one of the various "universal" binary storage formats (see Re^4: Storing state of execution -- Sereal?), or the problematic (see Re: Perl Storable problem (i Think) but fast Storable. See also: Re^2: Storing state of execution, Re^4: Storing state of execution And of course, for a quick hack that runs on known data, string `eval` is ok if it does the job AND the quick hack does not leave your environment. Don't let users use any tool that uses string `eval` just because it needs less code than a proper solution. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]
Re^5: The safety of string eval and block eval. by haukex (Archbishop) on Aug 16, 2016 at 07:45 UTC
Hi afoken, But for tasks like parsing configuration files ... Shameless plug of my own module ;-) Undumping Perl Regards, -- Hauke D	[reply]