Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46429
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.net designates 213.165.64.20 as permitted sender)
Message-ID: <4B27E7A4.6030503@gmx.net>
Date: Tue, 15 Dec 2009 20:46:44 +0100
User-Agent: Thunderbird 2.0.0.21 (X11/20090302)
MIME-Version: 1.0
To: internals <internals@lists.php.net>
References: <4B01A4C2.8030602@gmx.net> <4B27DD0B.1070303@gmx.net> <6571303B-82D2-43E4-8550-E2B9420BA241@pooteeweet.org>
In-Reply-To: <6571303B-82D2-43E4-8550-E2B9420BA241@pooteeweet.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Closures and $this: Please vote!
From: chris_se@gmx.net (Christian Seiler)

Hi Lukas,

> Call for a vote. This time around people cannot claim to not have had
> time to review the issue. Also back then we tried to play it safe
> because of the short time before we were to release. This time there is
> more time for this to mature if needed inside svn.

Ok, so then I call for a vote. Again, here are the options:

(0): No $this in closures, keep it that way. (keep PHP 5.3 behavior)

(A): Original closures implementation:
         $this is always the object context at
         closure creation. No possibility to do
         $someObject->closureProperty(...) and thus
         no possibility to extend objects!

(C): Javascript-like behaviour: Bind $this only when calling
     the closure as object method, else $this is undefined.

(D): JS-like behaviour on top of (A).
         Please look at the RFC as to why I consider it to be a
         *REALLY*, *REALLY* bad idea.

(A+): (A) + Closure::bind & Closure->bindTo for rebinding
      if this is wanted & the possibility to call a closure as an object
      method. (See last section of RFC for details)

My vote: (A+)

Regards,
Christian

PS: Note that I removed (B) from the possible options since I believe it
to be an EXTREMELY bad idea if one thinks it through. It was only added
to the RFC in order to give an overview over what was discussed
previously. Unless someone can make an extremely compelling case why I'm
wrong in this respect, I will refuse to implement (B).