Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42780
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <49788E2C.1040100@zend.com>
Date: Thu, 22 Jan 2009 18:18:04 +0300
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Christian Seiler <chris_se@gmx.net>
CC: Lukas Kahwe Smith <mls@pooteeweet.org>, =?UTF-8?B?RGF2aWQgWsO8bGtl?=
 <david.zuelke@bitextender.com>, Stanislav Malyshev <stas@zend.com>, 
 Marcus Boerger <helly@php.net>,
 Ionut Gabriel Stan <ionut.g.stan@gmail.com>, internals@lists.php.net, 
 =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@php.net>
References: <1016989528.20090112233204@marcus-boerger.de> <496BCD33.4080703@zend.com> <133861245.20090113225847@marcus-boerger.de> <496D2074.3070303@zend.com> <496DD269.4050701@gmail.com> <496E12CE.2080403@zend.com> <1956503865.20090117212630@marcus-boerger.de> <49743A89.3070607@zend.com> <995073772.20090119125721@marcus-boerger.de> <4974B2C8.5000704@zend.com> <DE2156A7-AD8D-4E16-9945-2D0FF7BD0AFA@pooteeweet.org> <49760CDF.2080006@gmx.net> <062274D5-9C20-4129-9597-145354A704EE@bitextender.com> <76BB6A71-62B3-4F0F-BB30-89CA7BAF5BD3@pooteeweet.org> <497880E8.5080202@gmx.net>
In-Reply-To: <497880E8.5080202@gmx.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC] Object extension, $this binding of closures, chat results
From: dmitry@zend.com (Dmitry Stogov)

I like the proposal. I got near the same idea few hours ago :)

The only difference is in binding/creation. You suggest

$obj->method2 = Closure::bind ($obj, function () { ... });

and I would prefer something like

create_prototype_method($obj, "method2", function () { ... });

But it's not a big deal. I can accept both.

Thanks. Dmitry.



Christian Seiler wrote:
> Hi everybody,
> 
> We had that chat that Lukas announced yesterday and I promised Lukas to
> sum up the results of that chat.
> 
> Problem was: There were only four people really there: Stas, Lukas,
> David and me. Lukas was interested in getting results in order to be
> able to release PHP 5.3 beta 1, Stas and I basically agreed on
> everything and unfortunately David didn't stay long enough in order to
> actually have a real discussion.
> 
> I'm not assigning blame here for not coming to anyone, I just wanted to
> make clear that we actually couldn't reach a consensus - or well,
> rather, Stas and I could but I don't think that's the way it should be.
> However, Lukas wants to release 5.3 beta 1 and I can really understand
> him that he doesn't want to drag this out infinitely.
> 
> I've written up the results of the discussion I had with Stas in the
> Wiki for everyone to read. I hope there's enough structure in it to make
> the main points clear. Please read it thoroughly before replying on-list
> in order to actually have a constructive dialogue.
> 
> Here it is: <http://wiki.php.net/rfc/closures/object-extension>
> 
> In order to be able to get beta 1 out as soon as possible, I propose the
> following:
> 
> 1. Remove $obj->closure_method() call syntax for beta1. Make sure
> rebinding of $this is not in beta1. Freeze tomorrow (Friday, Jan 23rd).
> 
> 2. Discuss my proposal and work out the details for adding manual
> rebining of $this in closures. Add that post-beta1 or if we don't get
> there in time at least post-5.3.0.
> 
> Alternatively, if you really don't like it at *all* the current way and
> can't imagine ever finding a consensus on my new proposal with
> bind()/bindTo(), then I propose the following:
> 
> 1. Remove $obj->closure_method() call syntax for beta1. Make sure
> rebinding of $this is not in beta1. Freeze tomorrow (Friday, Jan 23rd).
> This is exactly the state of alpha1 up to alpha3 so we won't actually be
> entering new territory with that.
> 
> 2. *Remove* OOP support from closures post-beta1 (i.e. for beta2) in
> order to leave all options open. Thus, closures will always be normal
> functions without access to $this or having a class scope and that may
> later be added in the fashion that we agree upon once we do that. (It
> will certainly still be possible to define closures inside class methods
> then, they just won't know about that.)
> 
> We definitely won't have to go so far as Johannes and remove closures
> entirely. Worst-case scenario, we remove OOP interaction and consider
> the proper way for that later.
> 
> On the other hand, I really would dislike stripping closures of OOP
> support completely - at least not after it was in there for about six
> months (!) and nobody *really* complained about that until now,
> immediately before beta1...
> 
> So, IMMEDIATE question: Is it ok for you to leave closure OOP support in
> beta1 on the level of alpha3 in order to allow Lukas and Johannes to
> finally release it? Even if you don't agree with my compromise proposal,
> please consider that in the worst case we can still remove all OOP
> support from closures after beta1.
> 
> Regards,
> Christian