I don't like "lexical" keyword, because it can be used anywhere in 
function (e.q. inside "if" or loop statement), however lexical variables 
  must be the part of lambda function definition.

We can think about some better syntax, like

function ($x, $y) ($a, $b, $c) {};
function ($x, $y) [$a, $b, $c] {};

I like "|" separator more, but the syntax of definition is not so 
important for me. It just must be clean, and the "lexical" keyword 
doesn't provide clean definition.

I don't like the idea to add methods at runtime, as it can break shared 
data structures in multi-threaded environment.

Thanks. Dmitry.

Federico Lebron wrote:
>  Hi Dmitry,
>  
>  As a lowly userspace developer, the | syntax is a bit confusing. If I 
>  see $x, $y | $a, $b, $c, my brain parses it as ($a, ($y | $a), $b, $c), 
>  since , has lower precedence than |. I'd think "syntax error", then 
>  "logical OR", but never "this refers to the variables I want imported to 
>  inside the closures".
>  
>  Also, I'd like "lexical" a bit more for the same reasons discussed in 
>  the short array syntax ([1,2]) topic: a user faced with function($x, $y 
>  | $a, $b, $c) has nowhere to search for what | means.
>  
>  I do, however, see the benefit of not changing the scanner and not 
>  breaking opcode caches. Would reusing "parent" be too much of a wtf?
>  
>  
>  Having little idea of how the internals work, would it be too 
>  complicated to hook "->" so if you say $obj->var(), and var holds a 
>  lambda function, for that function to be called instead of throwing a 
>  syntax error?
>  I know it seems hackish to add methods at runtime, but this would be to 
>  runkit's method addition what lambdas are to create_function.
>  IMO it would seem a bit more logical, if $obj->f = function(){echo 
>  "foo";};, to be able to do $obj->f() instead of $f = $obj->f; $f();, and 
>  knowing that $f() won't have access to $this (or at least, I wouldn't 
>  suppose it would in the second case).
>  
>  I also agree that shipping it with 5.3 would be a bit too rushed, since 
>  this, like any other feature, needs to be debugged thoroughly if it's 
>  going into production (and going to change the API). 5.4 and 6.0 don't 
>  seem so bad, though.
>  
>  
>  - Federico Lebron
>  
>  
>  Dmitry Stogov wrote:
> > Hi Christian,
> >
> > I took a look into your patch and found it too difficult.
> > So I implemented another patch (attached) which is based on your ideas.
> >
> >> From user's level of view it does exactly the same except for "lexical"
> > variables definition. I don't use any new reserver word because every
> > new reserved word is going to break some user code. I use the special
> > syntax for lambda function definition instead, which looks much clear
> > for me. The following code creates a lambda function with arguments $x,
> > $y and lexical variables $a, $b, $c.
> >
> > $a = function($x, $y | $a, $b $c) {};
> >
> > The patch shouldn't affect opcode caches and other extensions as it
> > doesn't change any structures. It uses the op_array->static_variables
> > for lexical variables.
> >
> > The patch also fixes several small issues and adds some missing
> > functionality which didn't allow preg_replace_callback() (and may be
> > others) to work with lambda functions. Now the following example works 
> > fine.
> >
> > <?php
> > class X {
> >   private function foo($x) {
> >     echo $x;
> >   }
> >   function bar($s) {
> >     return function ($x | $s) {
> >       static $n = 0;
> >       $n++;
> >       $s = $n.':'.$s;
> >       $this->foo($x[0].':'.$s);
> >     };
> >   }
> > }
> >
> > $x = new X;
> > $x = $x->bar("bye\n");
> > $s = 'abc';
> > preg_replace_callback('/[abc]/', $x, $s);
> > ?>
> >
> > It prints:
> >
> > a:1:bye
> > b:2:1:bye
> > c:3:2:1:bye
> >
> > Of course the patch doesn't break any existent tests.
> >
> > Please review.
> >
> > Thanks. Dmitry.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php