Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38488
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.62.56 cause and error)
To: internals@lists.php.net
MIME-Version: 1.0
Date: Fri, 20 Jun 2008 14:19:25 -0500
Message-ID: <303025b00a328c090e45eff2853a80e0@localhost>
User-Agent: RoundCube Webmail/0.1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
From: larry@garfieldtech.com (Larry Garfield)


On Fri, 20 Jun 2008 12:00:07 -0400, Robert Cummings <robert@interjinn.com> wrote:

>> function foo($a, $b, &$c) global ($d, &$e) {
>>   // ...
>> }
>>
>> $myfunc = lambda($a, $b, &$c) lexical ($d, &$e) {
>>   // ...
>> }
>>
>> That puts all the information in the declaration line with parallel
> syntax and semantics, and would even allow both by-val and by-ref usage
> for both lexical and global values.  The following would then be exactly
> equivalent functionality-wise:
>>
>> function foo() global (&$a) {
>>   // ...
>> }
>>
>> function foo() {
>>   global $a;
>>   // ...
>> }
>>
>> Is that too crazy an idea?
> 
> I like that, and also like the parenthesis on both parameter listings
> for greater readability. In a related question, would the following be a
> natural extension?

Agreed to it being better with parens than without.

> $myfun = lambda($a, $b, &$c) lexical ($d, &$e) global ($f, &$g){
>     // ...
> }

I realized that right after I sent my last email.  Yes, that would be the logical implication, and it somewhat parallels class Foo extends Bar implements Baz.  It seems if lexical values are going to have both by-val and by-ref uses at all, following the function parameter syntax for it has the lowest wtf factor.  I don't see global and $GLOBALS going away any time soon, though.

Mind you, I have no idea what the above would do to the engine-level implementation.  I would, however, much prefer explicit lexical declaration than implicit.  Implicit declaration in a "create variables on demand" language can have some very odd behaviors.  For instance, if you have a lambda that is declared in a function and has an internal variable it uses named $foo, and then 6 months later you add a $foo 20 lines up in the calling function, you now have a very strange and difficult bug to track down that won't show up until the lambda is invoked, which could be a long time later.

--Larry Garfield