Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38653
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.62.80 cause and error)
To: internals@lists.php.net
Date: Thu, 26 Jun 2008 21:58:03 -0500
User-Agent: KMail/1.9.9
References: <4856A547.3080801@gmx.net> <485B908D.7000106@zend.com> <4863C299.1080002@gmx.net>
In-Reply-To: <4863C299.1080002@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200806262158.03526.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
From: larry@garfieldtech.com (Larry Garfield)

On Thursday 26 June 2008 11:23:53 am Christian Seiler wrote:
> Hi Dmitry,
>
> > I'm fine if you'll improve my patch (It's mainly yours :)
>
> I updated my closures RFC: http://wiki.php.net/rfc/closures
> In my eyes, the following questions should be answered:
>
>   * Do you want closures in PHP?
>
>     I have not seen a single negative reaction to my proposal, so I
>     assume the answer to that is yes. ;-)

Yea. :-)

>   * Which syntax should be used for lexical variables? Should references
>     or copies be created by default?
>
>     This is far trickier.
>
>     First of all: There must *always* be the _possiblity_ to create
>     references, else you can't call it closures.
>
>     Second: I prefer the 'lexical' keyword, but I could live with the
>     use solution [function () use ($...)].
>
>     Third: There are several arguments against default referencing:
>
>       * (use syntax) As they look similar to parameters and normal
>                      parameters aren't passed by ref, this could be quite
>                      odd.
>       * Loop index WTFs (see proposal)
>       * Speed? (You always read that refs are slower in PHP than normal
>         variable copies. Is that actually true?)
>       * While it is possible to simply add an & in front of the variable
>         name to switch to refs in "no refs default" mode, there is no
>         obvious syntax to use copies in "refs default" mode other than
>         unsetting the variable in the parent scope immediately after
>         closure creation.
>
>     Fourth: There are several arguments for default referencing:
>
>       * (lexical syntax) global also creates a reference, why shouldn't
>                          lexical?
>       * Other languages *appear* to exhibit a very similar behaviour to
>         PHP if PHP created references. This is due to the fact that
>         other languages have a different concept of scope as PHP
>         does.
>
>     Although the list of against arguments appears to be longer, I do
>     prefer using references by default nevertheless. But that's just
>     my personal opinion.

I see these two issues as related, actually.  Consider:

$foo = function($a, &$b) {
  global $c;
  lexical $d;
  // ...
}

Since they look the same, you'd expect them to behave the same.  However, 
global will import by reference and lexical by value.  Hilarity ensues, and 
not the good kind.  Naturally changing the behavior of global in this case is 
out of the question, and as you point out defaulting to reference and having 
an extra flag (a la &) to force it to value is unprecedented.  I think most 
seem to agree that being able to pass by value or by reference at the 
developer's discretion is necessary.

However, something in the function signature itself would naturally follow the 
behavior of function arguments:

$foo = function($a, &$b) lexical ($d, &$e) {
  global $c;
  // ...
}

Here, $d and $e behave "as you'd expect them to", with the same visual parsing 
semantics as $a and $b.  That to me is a much lower wtf factor than having 
global and lexical keywords that look alike but behave differently.  I would 
therefore favor the signature-based syntax.

As an aside, I did use "lexical" in the second example above deliberately.  
Personally I don't think re-using "use" here is wise, as that will make it 
seem namespace related when in fact it is not.  I suspect the instances of 
function or constant names of "lexical" will be pretty minimal (although I 
admit to having no evidence to back up that suspicion.)

(I would much much rather have a closures implementation that used "use" than 
not one at all, mind you; I will still jump for joy if it lands using "use", 
I just think it would be better using "lexical".)

>   * Are you OK with the change that $this is only stored when needed?

Ignoring the compiler-level concerns, about which I know nothing useful, 
doesn't this introduce a bit of wtf?  "All lexically-imported variables must 
be explicit or they don't exist... oh yeah, except for $this because it's 
special."  

To which the question is: If you are able to magically determine if $this is 
used and optimize accordingly, why can't you for anything else?

To which the response is, I think: "Performance".  That's still something of 
an inconsistency, however.  Would it make the engine code any cleaner/messier 
if $this was required to be declared explicitly like everything else?

>   * Do you want closures in PHP 5.3?

As a PHP developer I'd love to have closures in 2 years when I'm able to use 
PHP 5.3 instead of 5 years when I'm able to use PHP 5.4  or PHP 6. :-)  I do 
understand the need to draw a line somewhere and justbloodyshipit(tm), 
however, so if that's the decision I can accept that.

> Regards,
> Christian

You so rock. :-)

-- 
Larry Garfield
larry@garfieldtech.com