Re: [PHP-DEV] [RFC] Object extension, $this binding of closures, chat results (was: Re: [PHP-DEV] [RFC] prototyping)

2009-01-22 Thread Larry Garfield
On Thursday 22 January 2009 8:21:28 am 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: 

IMO, a very large part of the problem is the implicit binding of $this when a 
closure happens to be defined inside a method of a class.  Every other variable 
that the closure inherits needs to be defined explicitly; that not only helps 
the parser but helps human readers.  Having $this be magically bound seems 
like a cause for confusion later on down the road.

That said, I very much like the proposal given in the RFC.  Rebinding of a 
closure should be an explicit operation that a future reader of the code can 
visually see and therefore know about.  That removes any potential WTFs when 
$this is suddenly $that even though you didn't mean for it to be.

Regarding the details, wherein lives the devil:

- If a closure is bound to an object and does NOT make use of $this, do we 
still want to throw a warning if it is called?  In that case the binding is 
irrelevant anyway.  (That goes back to the point about an implicit initial 
bind, which I am still not convinced is wise.)

- IMO, once a closure has been bound to an object, its $this should have all 
the same access as a method defined literally on that object's class.  That is, 
it should have private/protected access the same as a "normal" method.

- I am a little unclear on what the expected cloning behavior is.  Do closures 
have a clone method?  Take the following example:

class A {
  function getClosure() {
$var = new Foo();
return function() use ($var) {
  return $var->something;
}
  }
}

$a = new A;
$o = new stdClass();
$closure = $a->getClosure();
$o->foo = $closure->bindTo($o);

Now, are $closure->var and $o->foo->var the same object or no?  I'm assuming 
they are from the RFC, but then how do you implement a deep clone of the 
closure on binding if you need to?

-- 
Larry Garfield
la...@garfieldtech.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Object extension, $this binding of closures, chat results

2009-01-22 Thread Pierre Joye
On Thu, Jan 22, 2009 at 9:12 PM, Lukas Kahwe Smith  wrote:
>
> On 22.01.2009, at 21:08, Pierre Joye wrote:
>>
>> I'm talking about the features we already have, not about adding more
>> major features. If one of the new features is not complete and we know
>> it, why do you want to go ahead then? I can't find any good reason.
>
>
> because it means all the other features have to wait to be released. this
> includes all the features that will be released as part of 5.3 ... and all
> the features that are waiting for after 5.3.
>
> its really time we think release oriented .. not because our money depends
> on it .. but simply because its the right thing to do to at this point.

Exactly, release oriented.

If a feature was planed for a release, it has to be done in the best
possible way, that means solving known issue as far as it is possible.

In this case, both requirements are present. It was planed and issues
have been identified and there is on going discussions about the best
solution. That's why I do not (and will surely never) understand why
we should go ahead with 5.3.0 and think about fixing that after. That
makes no sense to me.

And for anything new coming around and not planed for 5.3.0, I fully
agree with you.


Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Object extension, $this binding of closures, chat results

2009-01-22 Thread Lukas Kahwe Smith


On 22.01.2009, at 21:08, Pierre Joye wrote:

I'm talking about the features we already have, not about adding more
major features. If one of the new features is not complete and we know
it, why do you want to go ahead then? I can't find any good reason.



because it means all the other features have to wait to be released.  
this includes all the features that will be released as part of  
5.3 ... and all the features that are waiting for after 5.3.


its really time we think release oriented .. not because our money  
depends on it .. but simply because its the right thing to do to at  
this point.


regards,
Lukas Kahwe Smith
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Object extension, $this binding of closures, chat results

2009-01-22 Thread Stanislav Malyshev

Hi!


I'm talking about the features we already have, not about adding more
major features. If one of the new features is not complete and we know
it, why do you want to go ahead then? I can't find any good reason.


You can argue every feature is not complete because there's always 
something somebody wants to add or change. However the good reason it is 
complete enough to be useful, and if we start right now to discuss yet 
another set of new features we won't have release until 2010 or 2011 - 
meaning new features we *already* have would be useless, since nobody 
could use them before we actually *release* them. What happen to 
"release often", folks? Why you must stuff every single idea anybody has 
in this particular version?

--
Stanislav Malyshev, Zend Software Architect
s...@zend.com   http://www.zend.com/
(408)253-8829   MSN: s...@zend.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Object extension, $this binding of closures, chat results

2009-01-22 Thread Pierre Joye
On Thu, Jan 22, 2009 at 8:48 PM, Lukas Kahwe Smith  wrote:
>
> On 22.01.2009, at 20:39, Pierre Joye wrote:
>
>> hi,
>>
>> On Thu, Jan 22, 2009 at 7:36 PM, Christian Seiler 
>> wrote:
>>>
>>> Hi again,
>>>
>>> ok, I just verified that the current PHP 5.3 CVS has the same behaviour
>>> as PHP 5.3 alpha 3 (which is the original design). So basically, I'd
>>> suggest the following:
>>>
>>> * Feature freeze as Lukas and Johannes had planned tomorrow with *no*
>>>  more changes wrt. closures for beta1, then release beta1.
>>>
>>> * For post-beta1: Discuss which of the following options we want to
>>>  take:
>>>
>>>  a) My Closure::bind() compromise
>>>  b) Leave as is in order to add Closure::bind() later (5.3.1, 5.4,
>>> 6.0) when we've discussed all the details.
>>>  c) Drop $this/OOP support from closures for beta2 in order to be
>>> able to discuss this properly for a later version.
>>
>> If we know limitations, issues or design problems now and they can be
>> fixed in a relatively short delay (within a couple of weeks), then I
>> do not see why we should release 5.3.0 with them. We are in a test
>> phase and that means that we will have to change one thing or another,
>> even after beta1. That's what I meant in my previous posts.
>
> right .. we are in a test phase .. not experiment phase. the time for
> experiments is over. we have enough features for a couple releases. so if we
> find that some feature is not done yet .. or that we might need to break BC
> later if we release the feature now, then we should strip the feature until
> we do not foresee possible BC breaks and move on.
>
> if we keep delaying a few weeks here and there, we will do PHP a greater
> disservice. as johannes has pointed out we have delayed some features
> because we wanted to focus on getting 5.3 out. if necessary we can always
> have a PHP 5.4 just as well.

I'm talking about the features we already have, not about adding more
major features. If one of the new features is not complete and we know
it, why do you want to go ahead then? I can't find any good reason.

-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Object extension, $this binding of closures, chat results

2009-01-22 Thread Lukas Kahwe Smith


On 22.01.2009, at 20:39, Pierre Joye wrote:


hi,

On Thu, Jan 22, 2009 at 7:36 PM, Christian Seiler   
wrote:

Hi again,

ok, I just verified that the current PHP 5.3 CVS has the same  
behaviour

as PHP 5.3 alpha 3 (which is the original design). So basically, I'd
suggest the following:

* Feature freeze as Lukas and Johannes had planned tomorrow with *no*
 more changes wrt. closures for beta1, then release beta1.

* For post-beta1: Discuss which of the following options we want to
 take:

  a) My Closure::bind() compromise
  b) Leave as is in order to add Closure::bind() later (5.3.1, 5.4,
 6.0) when we've discussed all the details.
  c) Drop $this/OOP support from closures for beta2 in order to be
 able to discuss this properly for a later version.


If we know limitations, issues or design problems now and they can be
fixed in a relatively short delay (within a couple of weeks), then I
do not see why we should release 5.3.0 with them. We are in a test
phase and that means that we will have to change one thing or another,
even after beta1. That's what I meant in my previous posts.


right .. we are in a test phase .. not experiment phase. the time for  
experiments is over. we have enough features for a couple releases. so  
if we find that some feature is not done yet .. or that we might need  
to break BC later if we release the feature now, then we should strip  
the feature until we do not foresee possible BC breaks and move on.


if we keep delaying a few weeks here and there, we will do PHP a  
greater disservice. as johannes has pointed out we have delayed some  
features because we wanted to focus on getting 5.3 out. if necessary  
we can always have a PHP 5.4 just as well.


regards,
Lukas Kahwe Smith
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Object extension, $this binding of closures, chat results

2009-01-22 Thread Pierre Joye
hi,

On Thu, Jan 22, 2009 at 7:36 PM, Christian Seiler  wrote:
> Hi again,
>
> ok, I just verified that the current PHP 5.3 CVS has the same behaviour
> as PHP 5.3 alpha 3 (which is the original design). So basically, I'd
> suggest the following:
>
>  * Feature freeze as Lukas and Johannes had planned tomorrow with *no*
>   more changes wrt. closures for beta1, then release beta1.
>
>  * For post-beta1: Discuss which of the following options we want to
>   take:
>
>a) My Closure::bind() compromise
>b) Leave as is in order to add Closure::bind() later (5.3.1, 5.4,
>   6.0) when we've discussed all the details.
>c) Drop $this/OOP support from closures for beta2 in order to be
>   able to discuss this properly for a later version.

If we know limitations, issues or design problems now and they can be
fixed in a relatively short delay (within a couple of weeks), then I
do not see why we should release 5.3.0 with them. We are in a test
phase and that means that we will have to change one thing or another,
even after beta1. That's what I meant in my previous posts.

so in short:

-1 for option b)
+1 to solve the issue for 5.3.0-final before beta1.

Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Object extension, $this binding of closures, chat results

2009-01-22 Thread Christian Seiler
Hi again,

ok, I just verified that the current PHP 5.3 CVS has the same behaviour
as PHP 5.3 alpha 3 (which is the original design). So basically, I'd
suggest the following:

 * Feature freeze as Lukas and Johannes had planned tomorrow with *no*
   more changes wrt. closures for beta1, then release beta1.

 * For post-beta1: Discuss which of the following options we want to
   take:

a) My Closure::bind() compromise
b) Leave as is in order to add Closure::bind() later (5.3.1, 5.4,
   6.0) when we've discussed all the details.
c) Drop $this/OOP support from closures for beta2 in order to be
   able to discuss this properly for a later version.

Regards,
Christian

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] [RFC] Object extension, $this binding of closures, chat results (was: Re: [PHP-DEV] [RFC] prototyping)

2009-01-22 Thread Christian Seiler
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: 

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php