On Mon, March 19, 2007 5:33 pm, Stanislav Malyshev wrote: >> Can't you just take the body of "create_function" with the syntax of >> the patch, and marry those two? > > Well, that'd be a bit hard since the whole difference is that > create_function is runtime (thus having access to run-time values) > while > anon-func we are trying to do here is compile-time (at least it makes > a > lot of sense to do it compile-time). We could of course just leave the > scope thing alone and say "want access to other scope? tough luck, use > create_function/eval or globals".
I thought the original driving purpose was to not have the gnarly quoting mess of create_function. Yes, in the implementation, it turned out to be a compile-time closure. Does that mean we really WANT to go there, just because it falls out easily, or does that mean we should step back and look at the original goal and see if maybe we've gone off-track? >> How does the current create_function handle this same scope issue? > > It doesn't AFAIK :) Since it's a close relative of eval, it can import > values of variables by inserting ones into function string, but > nothing > more (i.e. you couldn't put an object there, and couldn't refer to a > variable - only insert it's value). I'd be perfectly happy if PHP's "anonymous" functions had the nice syntax and no funky weird stuff about closure, a la eval/create_function, personally. I don't need the closures, but when I need a quickie anon function in PHP, I just want something less ugly than create_function. That's just my personal preference, of course. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
