Hi,
>> My suggestion is to wait until the 15th of January (that's one month
>> since I started this thread) and that should have been enough time of
>> everybody.
>
> So, it's 18th - are we moving forward with this?
Yes, Sorry, I've been extremely busy for the last two months, I'll get
back to t
Hi!
My suggestion is to wait until the 15th of January (that's one month
since I started this thread) and that should have been enough time of
everybody.
So, it's 18th - are we moving forward with this?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)25
Hello again,
A quick summary of the votes so far (since 15th December):
internals@ votes:
0: (1) Alexey Zakhlestin
A: (1) Hannes Magnusson
C: (0) -
D: (0) -
A+: (2) Christian Seiler, Joey Smith
AS: (1) Stanislav Malyshev
---
5 votes
[AS is Stas' version with bin
I vote for (A). bind() and bindTo() seem messy to me. However, I
mostly vote for no implicit $this changes in closures (no
javascript-like behaviour), so (A+) approach would be much better than
(C) or (D). (0) case is not my choice, because I really would like to
see $this support in closures back.
On Tue, Dec 15, 2009 at 08:46:44PM +0100, Christian Seiler wrote:
> (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)
+1 for "A+" with class scope option 2
I'm
On Tuesday 15 December 2009 1:46:44 pm Christian Seiler wrote:
> 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
>
Christian Seiler wrote
>
> 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
2009/12/15 Ionut G. Stan :
> A+, but I'm not an internal dev.
>
>
> On 12/15/2009 21:46, Christian Seiler wrote:
>>
>> 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 shor
Hi,
Maybe I don't exactly understand the need for closureProperty(); also,
I haven't read the rfc ;-)
My understanding would be that you can treat it as a callable object, like so:
$a = function($msg) { echo $this->id, ": ", $msg, " [ calls: ",
++$this->calls, "]";
}
$a->id = 123;
$a("hello wor
A+, but I'm not an internal dev.
On 12/15/2009 21:46, Christian Seiler wrote:
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
On 15.12.2009, at 22:46, Christian Seiler wrote:
> 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)
I vote for (0)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
Hi,
>> Ok, so then I call for a vote. Again, here are the options:
>
> A+, no direct method calling (get/call problem would be messy)
I don't quite follow: Why A+ if no direct method calling? What would be
the point of allowing bindTo() if $obj->closureProp() doesn't work
anyway? If you don't wa
Hi!
> Ok, so then I call for a vote. Again, here are the options:
A+, no direct method calling (get/call problem would be messy)
one additional thing:
$a = static function () {}
should leave $this not bound (in case for some reason you don't want it
to be bound, e.g. to avoid keeping reference
On Tue, Dec 15, 2009 at 20:46, Christian Seiler wrote:
> (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!
+1
Pre
14 matches
Mail list logo
