On 8/16/05, Tim King <[EMAIL PROTECTED]> wrote:
> Uri Guttman <[EMAIL PROTECTED]>:
[...]
> > I agree that Perl's behaviour is logical. However it is
> > inconvenient. And from the point of the person who is
> > trying to use make_generator, it causes internal details
> > to matter too much.
>
> Hi, Ben and all. I agree that using eval here is wrong. But I still
> don't see action at a distance.
You can argue about whether it is action at a distance, but you
have tight coupling between the internals of make_generator
and the string passed into it that was generated from very far
away.
> The problem in this example is that make_generator doesn't make a
> generator. Rather it creates a sub in its own context using code passed
> in as a string. The passed-in code can manipulate a unique variable "$x"
> common between all the returned subs. It instantiates a dynamic method
> that can use a private member "$x," which is one of the things eval() is
> actually good for.
I know full well what the problem is. And the result is that you
cannot consider using code generation for a situation like this.
> > A workaround, of course, is to tell the person to use
> > global variables.
>
> What's wrong with the following?
>
> sub foo {
> my $x = 7;
> my $generator = sub{++$x};
> print $generator->() for 1..5;
> }
In the simple case, nothing. But in general you're now
prevented from adding various kinds of syntactic sugar,
manipulating the passed in code before compiling it, etc.
Sometimes those limitations are annoying.
Of course those techniques don't work well in Perl
anyways because source filters always break. (Perl is
not Lisp...)
> Note that $generator can be passed around and invoked from anywhere
> anyplace in the code with the same result. It is a true coroutine, which
> I assume is what you wanted.
It is not a coroutine. It is a closure. It is closing over the right
environment. In the specific case this is right. In the general
case it is nice to have the option of doing something else.
Cheers,
Ben
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
