[PHP-DEV] closures and $this

[Harald Lapp]

hello,

i would like to ask what's the state of $this (and 'self') in closures. 
there seems to be no news on this topic for several month now. php 5.3.3 
was just released and still nothing has changed regarding this. so i 
would like to ask, for which php release a solution is planned.


thanks very much!

harald

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

[PHP-DEV] Closures and $this

[Christian Seiler]

Hi,

since a few months have passed since the last discussion on this topic
and perhaps people had time to gather some experience with the current
closure implementation in PHP 5.3 I'd like to restart the debate on
$this in closures and object extension.

Foreword: The discussion should center on the future behaviour of PHP 6
ONLY. Whether or not a backport is even possible (binary compability
etc.) or should even be done should be topic of a separate discussion
and should *NOT* influence the decision. The ONLY goal of this
discussion should be to agree on a SANE way of implementing $this for
closures for PHP 6.

I've updated the original RFC I wrote a tiny bit (I didn't change much):



The basic outline is the following:

 * In the first section I explain the general issue.
 * In the second section I show the proposals that were made on
   internals@ before I wrote the RFC.
 * In the third section I compare the approaches and explain why
   the approaches (B) and (D) are inconsistent.
 * In the fourth section I propose a new approach (bindTo) that
   was only briefly discussed after the original RFC.

Please read the complete RFC and try to understand the points I'm trying
to make. If something is unclear, *please* ask first. In the past
discussion I had the impression that a lot of people understood only
partial aspects of the problem which made the discussion extremely
noisy. I believe that is a disservice to the issue. However, now we have
the huge advantage of NOT having an immanent deadline for a release. I
hope this will enable a consensus on this issue.

Discuss away!

Regards,
Christian


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

[PHP-DEV] Closures and $this: again!

[Stanislav Malyshev]

Hi!

I see that still nothing happens with closures and $this, and it sounds 
like the overall feeling was that we still want $this in closures work, 
and most are inclined to A here:

http://marc.info/?l=php-internals&m=126090656804423&w=2
or some version of it.

So, can anybody provide any reason not to resurrect $this in closures in 
trunk? If not, I intend to do it next week (unless somebody is already 
working on it - don't want to step on anybody's toes :).

--
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] closures and $this

[Adam Harvey]

On 23 July 2010 03:05, Harald Lapp  wrote:
> i would like to ask what's the state of $this (and 'self') in closures.
> there seems to be no news on this topic for several month now. php 5.3.3 was
> just released and still nothing has changed regarding this. so i would like
> to ask, for which php release a solution is planned.

$this support in closures isn't intended to be included in the 5.3
series — the result of the vote late last year was the "modified
proposal A" documented at
http://wiki.php.net/rfc/closures/object-extension, and that has been
implemented on trunk since April, so will be in the next major version
of PHP, whatever that's actually numbered as.

Adam

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

Re: [PHP-DEV] closures and $this

[Harald Lapp]

Am 23.07.10 06:05, schrieb Adam Harvey:

On 23 July 2010 03:05, Harald Lapp  wrote:

i would like to ask what's the state of $this (and 'self') in closures.
there seems to be no news on this topic for several month now. php 5.3.3 was
just released and still nothing has changed regarding this. so i would like
to ask, for which php release a solution is planned.


$this support in closures isn't intended to be included in the 5.3
series — the result of the vote late last year was the "modified
proposal A" documented at
http://wiki.php.net/rfc/closures/object-extension, and that has been
implemented on trunk since April, so will be in the next major version
of PHP, whatever that's actually numbered as.



i understand -- i hoped for a more early release, but this are good news 
for me anyway. is there a good place for end-users to stay up-to-date on 
such topics? i'm looking at the php RFCs every ones in a while, but 
there was no update regarding closures/$this ...


thanks for your help!

harald

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

Re: [PHP-DEV] closures and $this

[Harald Lapp]

Am 23.07.10 06:05, schrieb Adam Harvey:

On 23 July 2010 03:05, Harald Lapp  wrote:

i would like to ask what's the state of $this (and 'self') in closures.
there seems to be no news on this topic for several month now. php 5.3.3 was
just released and still nothing has changed regarding this. so i would like
to ask, for which php release a solution is planned.


$this support in closures isn't intended to be included in the 5.3
series — the result of the vote late last year was the "modified
proposal A" documented at
http://wiki.php.net/rfc/closures/object-extension, and that has been
implemented on trunk since April, so will be in the next major version
of PHP, whatever that's actually numbered as.



i understand -- i hoped for a more early release, but this are good news 
for me anyway. is there a good place for end-users to stay up-to-date on 
such topics? i'm looking at the php RFCs every ones in a while, but 
there was no update regarding closures/$this ...


thanks for your help!

harald

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

Re: [PHP-DEV] closures and $this

[Lukas Kahwe Smith]

On 23.07.2010, at 11:35, Harald Lapp wrote:

> Am 23.07.10 06:05, schrieb Adam Harvey:
>> On 23 July 2010 03:05, Harald Lapp  wrote:
>>> i would like to ask what's the state of $this (and 'self') in closures.
>>> there seems to be no news on this topic for several month now. php 5.3.3 was
>>> just released and still nothing has changed regarding this. so i would like
>>> to ask, for which php release a solution is planned.
>> 
>> $this support in closures isn't intended to be included in the 5.3
>> series — the result of the vote late last year was the "modified
>> proposal A" documented at
>> http://wiki.php.net/rfc/closures/object-extension, and that has been
>> implemented on trunk since April, so will be in the next major version
>> of PHP, whatever that's actually numbered as.
>> 
> 
> i understand -- i hoped for a more early release, but this are good news for 
> me anyway. is there a good place for end-users to stay up-to-date on such 
> topics? i'm looking at the php RFCs every ones in a while, but there was no 
> update regarding closures/$this ...


subscribe to the RSS feed on the wiki.
also .. the time is now to discuss the future and get changes into trunk

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] Closures and $this

[Mathieu Suen]

Christian Seiler a écrit :

Hi,

since a few months have passed since the last discussion on this topic
and perhaps people had time to gather some experience with the current
closure implementation in PHP 5.3 I'd like to restart the debate on
$this in closures and object extension.

Foreword: The discussion should center on the future behaviour of PHP 6
ONLY. Whether or not a backport is even possible (binary compability
etc.) or should even be done should be topic of a separate discussion
and should *NOT* influence the decision. The ONLY goal of this
discussion should be to agree on a SANE way of implementing $this for
closures for PHP 6.

I've updated the original RFC I wrote a tiny bit (I didn't change much):



The basic outline is the following:

 * In the first section I explain the general issue.
 * In the second section I show the proposals that were made on
   internals@ before I wrote the RFC.
 * In the third section I compare the approaches and explain why
   the approaches (B) and (D) are inconsistent.
 * In the fourth section I propose a new approach (bindTo) that
   was only briefly discussed after the original RFC.

Please read the complete RFC and try to understand the points I'm trying
to make. If something is unclear, *please* ask first. In the past
discussion I had the impression that a lot of people understood only
partial aspects of the problem which made the discussion extremely
noisy. I believe that is a disservice to the issue. However, now we have
the huge advantage of NOT having an immanent deadline for a release. I
hope this will enable a consensus on this issue.

Discuss away!

Regards,
Christian





IMHO I would put it that way: do you want to staticaly or dynamicaly 
bind $this?  The same question apply for temporary varaible.

IIRC you statically bind temporary with the 'use(..)' syntaxe.
So why $this should be different. I agree on proposition A.




-- Mathieu Suen



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

Re: [PHP-DEV] Closures and $this

[Chris Stockton]

Hello,

On Tue, Nov 17, 2009 at 2:59 AM, Mathieu Suen
 wrote:
> Christian Seiler a écrit :
>>
>> Hi,
>>
>> since a few months have passed since the last discussion on this topic
>> and perhaps people had time to gather some experience with the current
>> closure implementation in PHP 5.3 I'd like to restart the debate on
>> $this in closures and object extension.

I believe that (D) wins my vote, and it convinces me twice. Once
because I believe it is the most intuitive for users (A), and twice
because I believe it is also the most useful (C) for users. In my
opinion It seems the most "PHP" way.

-Chris

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

Re: [PHP-DEV] Closures and $this

[Mathieu Suen]

Chris Stockton a écrit :

Hello,

On Tue, Nov 17, 2009 at 2:59 AM, Mathieu Suen
 wrote:

Christian Seiler a écrit :

Hi,

since a few months have passed since the last discussion on this topic
and perhaps people had time to gather some experience with the current
closure implementation in PHP 5.3 I'd like to restart the debate on
$this in closures and object extension.


I believe that (D) wins my vote, and it convinces me twice. Once
because I believe it is the most intuitive for users (A), and twice
because I believe it is also the most useful (C) for users. In my
opinion It seems the most "PHP" way.

-Chris



(D) is quite inconstant:

$block = $foo->closur;

$foo->closur();
$block();

This would produce 2 different output.
For (C) here is my objection:

Suppose that we are in a MVC pattern.
In a controller on could do:

$model->onFailDo(function () {$this->reportError()});
$model->save();


In the model side:

public function onFailDo($block)
{
$this->signalFailure = $block
}

public function save()
{
//... Something wrong happen
return $this->signalFailure();
}

If you dynamically bind the $this you are obliged to treat the error 
reporting in the model which is not a good idea. Even worst you can't 
even catch up the error in the controller.
It also mean that the closure is getting tightly coupled with anyone who 
is using it. And passing closure to different object is like spreading 
dependency over all the system.


-- Mathieu Suen

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

Re: [PHP-DEV] Closures and $this

[Victor Bolshov]

Hi.

Personally, I beleive that (A) approach is the best: "bind $this to
the object scope at creation" and never change it, issue error when
$this is used where not available. It also seems to me like this way
it could be implemented with better performance, am I right?

Dynamically changing $this introduces confusion. You can use
$this->foo or $this->bar() inside a closure, but when $this
dynamically changes - you cannot be sure that "foo" property or "bar"
method is still there. Furthermore, dynamic approach introduces even
more mess when thinking about availability of private/protected class
members.

Consider this code:

class Foo {
  private $closure;
  function __construct()
  {
/* It seems natural to me that, doing this assignment from within the class,
   one can use private members inside the closure */
$this->closure = function() { $this->privateMethod(); };
  }
  function setClosure($closure)
  {
$this->closure = $closure;
  }
  function getClosure()
  {
return $this->closure;
  }
}

$foo = new Foo();
$foo->getClosure()->__invoke();// #CALL-1
$foo->setClosure(function() {
  /*
  But is it good to use private members here? It seems like it would
break encapsulation,
  and the information that the class was designed to hide - is now
made available in public access,
  although indirect.
  */
  $this->privateMethod();
});
$foo->getClosure()->__invoke();// #CALL-2

In the end, I would like PHP to issue error when $this is used in
#CALL-2 but to continue working on #CALL-1.

The (A) approach seems to me more predictable, more simple, it has
less information the developer needs to keep in mind when using
closures.

2009/11/17 Mathieu Suen :
> Chris Stockton a écrit :
>>
>> Hello,
>>
>> On Tue, Nov 17, 2009 at 2:59 AM, Mathieu Suen
>>  wrote:
>>>
>>> Christian Seiler a écrit :

 Hi,

 since a few months have passed since the last discussion on this topic
 and perhaps people had time to gather some experience with the current
 closure implementation in PHP 5.3 I'd like to restart the debate on
 $this in closures and object extension.
>>
>> I believe that (D) wins my vote, and it convinces me twice. Once
>> because I believe it is the most intuitive for users (A), and twice
>> because I believe it is also the most useful (C) for users. In my
>> opinion It seems the most "PHP" way.
>>
>> -Chris
>>
>
> (D) is quite inconstant:
>
> $block = $foo->closur;
>
> $foo->closur();
> $block();
>
> This would produce 2 different output.
> For (C) here is my objection:
>
> Suppose that we are in a MVC pattern.
> In a controller on could do:
>
> $model->onFailDo(function () {$this->reportError()});
> $model->save();
>
>
> In the model side:
>
> public function onFailDo($block)
> {
>        $this->signalFailure = $block
> }
>
> public function save()
> {
>        //... Something wrong happen
>        return $this->signalFailure();
> }
>
> If you dynamically bind the $this you are obliged to treat the error
> reporting in the model which is not a good idea. Even worst you can't even
> catch up the error in the controller.
> It also mean that the closure is getting tightly coupled with anyone who is
> using it. And passing closure to different object is like spreading
> dependency over all the system.
>
> -- Mathieu Suen
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Regards,
Victor

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

Re: [PHP-DEV] Closures and $this

[Richard Quadling]

2009/11/16 Christian Seiler :
> Hi,
>
> since a few months have passed since the last discussion on this topic
> and perhaps people had time to gather some experience with the current
> closure implementation in PHP 5.3 I'd like to restart the debate on
> $this in closures and object extension.
>
> Foreword: The discussion should center on the future behaviour of PHP 6
> ONLY. Whether or not a backport is even possible (binary compability
> etc.) or should even be done should be topic of a separate discussion
> and should *NOT* influence the decision. The ONLY goal of this
> discussion should be to agree on a SANE way of implementing $this for
> closures for PHP 6.
>
> I've updated the original RFC I wrote a tiny bit (I didn't change much):
>
> 
>
> The basic outline is the following:
>
>  * In the first section I explain the general issue.
>  * In the second section I show the proposals that were made on
>   internals@ before I wrote the RFC.
>  * In the third section I compare the approaches and explain why
>   the approaches (B) and (D) are inconsistent.
>  * In the fourth section I propose a new approach (bindTo) that
>   was only briefly discussed after the original RFC.
>
> Please read the complete RFC and try to understand the points I'm trying
> to make. If something is unclear, *please* ask first. In the past
> discussion I had the impression that a lot of people understood only
> partial aspects of the problem which made the discussion extremely
> noisy. I believe that is a disservice to the issue. However, now we have
> the huge advantage of NOT having an immanent deadline for a release. I
> hope this will enable a consensus on this issue.
>
> Discuss away!
>
> Regards,
> Christian
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

I think the consistent mechanism is to have the binding done at
runtime and to be explicitly stated by the userland code.

$fn = function() use() bind($x) {
  // $this = whatever was bound, in this example $x
};

so, inside a class...

$fn = function() use() bind($this) {
  // $this would be the same as the $this of the class.
};

As for public/protected/private ...

$fn = function() use() bind() access(CLOSURE_PUBLIC |
CLOSURE_PROTECTED | CLOSURE_PRIVATE) {};

to control which properties/methods were available.

I'd be concerned about that this could be a shortcut to access
non-public properties/methods.

Richard.

-
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

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

Re: [PHP-DEV] Closures and $this

[Stanislav Malyshev]

Hi!


As for public/protected/private ...

$fn = function() use() bind() access(CLOSURE_PUBLIC |
CLOSURE_PROTECTED | CLOSURE_PRIVATE) {};


I have very hard time imagining somebody that would be comfortable using 
such a construct. What happened to keeping it simple? And why every 
tiniest feature of every remotest imaginable use case has to be brought 
into the language syntax?


--
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] Closures and $this

[Chris Stockton]

Hello,

On Wed, Nov 18, 2009 at 11:44 AM, Stanislav Malyshev  wrote:
> I have very hard time imagining somebody that would be comfortable using
> such a construct. What happened to keeping it simple? And why every tiniest
> feature of every remotest imaginable use case has to be brought into the
> language syntax?

That syntax made my eyes hurt, but I think really the problem is that
people want to dynamically add methods with $this in the closure
pointing the the object it has been attached too. Really I like A. but
can see cases for rebinding (C). Maybe a magic method like
__attach(string methodName, function method) that would rebind $this
in closures would be a solution. But it would be the first magic
method I can think of that isn't overridden by the defining class.

$o = new StdClass;
$o->bar = 'bar';
$o->__attach('foo', function() { echo $this->bar; });
$o->foo(); // bar

Just a thought.

-Chris

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

Re: [PHP-DEV] Closures and $this

[Stanislav Malyshev]

Hi!


That syntax made my eyes hurt, but I think really the problem is that
people want to dynamically add methods with $this in the closure
pointing the the object it has been attached too. Really I like A. but


We can add method to Closure class to allow that. See Closure::bind and 
 bindTo in the proposal.


--
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] Closures and $this

[Jelrik van Hal]

Victor Bolshov wrote:

Hi.

Personally, I beleive that (A) approach is the best: "bind $this to
the object scope at creation" and never change it, issue error when
$this is used where not available. It also seems to me like this way
it could be implemented with better performance, am I right?

Dynamically changing $this introduces confusion. You can use
$this->foo or $this->bar() inside a closure, but when $this
dynamically changes - you cannot be sure that "foo" property or "bar"
method is still there. Furthermore, dynamic approach introduces even
more mess when thinking about availability of private/protected class
members.

Consider this code:

class Foo {
  private $closure;
  function __construct()
  {
/* It seems natural to me that, doing this assignment from within the class,
   one can use private members inside the closure */
$this->closure = function() { $this->privateMethod(); };
  }
  function setClosure($closure)
  {
$this->closure = $closure;
  }
  function getClosure()
  {
return $this->closure;
  }
}

$foo = new Foo();
$foo->getClosure()->__invoke();// #CALL-1
$foo->setClosure(function() {
  /*
  But is it good to use private members here? It seems like it would
break encapsulation,
  and the information that the class was designed to hide - is now
made available in public access,
  although indirect.
  */
  $this->privateMethod();
});
$foo->getClosure()->__invoke();// #CALL-2

In the end, I would like PHP to issue error when $this is used in
#CALL-2 but to continue working on #CALL-1.

The (A) approach seems to me more predictable, more simple, it has
less information the developer needs to keep in mind when using
closures.

2009/11/17 Mathieu Suen :

Chris Stockton a écrit :

Hello,

On Tue, Nov 17, 2009 at 2:59 AM, Mathieu Suen
 wrote:

Christian Seiler a écrit :

Hi,

since a few months have passed since the last discussion on this topic
and perhaps people had time to gather some experience with the current
closure implementation in PHP 5.3 I'd like to restart the debate on
$this in closures and object extension.

I believe that (D) wins my vote, and it convinces me twice. Once
because I believe it is the most intuitive for users (A), and twice
because I believe it is also the most useful (C) for users. In my
opinion It seems the most "PHP" way.

-Chris


(D) is quite inconstant:

$block = $foo->closur;

$foo->closur();
$block();

This would produce 2 different output.
For (C) here is my objection:

Suppose that we are in a MVC pattern.
In a controller on could do:

$model->onFailDo(function () {$this->reportError()});
$model->save();


In the model side:

public function onFailDo($block)
{
   $this->signalFailure = $block
}

public function save()
{
   //... Something wrong happen
   return $this->signalFailure();
}

If you dynamically bind the $this you are obliged to treat the error
reporting in the model which is not a good idea. Even worst you can't even
catch up the error in the controller.
It also mean that the closure is getting tightly coupled with anyone who is
using it. And passing closure to different object is like spreading
dependency over all the system.

-- Mathieu Suen

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






Hi,

Victor, I do wholeheartedly agree with you about the mess things will be 
when allowing $this to refer to different things in different contexts 
of calling the same closure (B, C and D): I think it'll prove very 
difficult to keep track of which call will end up doing exactly what in 
which environment.


What I'm not really aware of are any big advantages of rebinding $this 
to the local environment of the calling code: isn't it just making 
$this/things unnecessarily difficult?


Also, I'm wondering why people think there should be a $this inside a 
closure. As stated in the RFC/Wiki, closures are not thought out to be 
used alongside OO-code. Why would we want to couple them? I see the use 
of closures, but not as OO-related tools using $this. What is the 
problem with proposal (0), leaving it as it is now?


-jelrikvh

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

Re: [PHP-DEV] Closures and $this

[Stanislav Malyshev]

Hi!


If php-people really would like rebinding $this, I beleive this should
be done via method like Closure->bindTo() - to make the fact of
rebinding clear in the code.

However, there is a problem with rebinding $this - that was not
mentioned yet, I think.


This can be a problem, but since PHP is not a compiled language, this 
problem already exists - all method names are only checked in runtime 
anyway, so it doesn't matter if you rebind the closure or not. Of 
course, with rebinding you can easily shoot yourself in the foot by 
calling non-existing method - but so you can with $foo->$bar() or $foo() 
or a number of other ways. So I think if this construct is expressed in 
a way that makes the intent clear (i.e., no implicit rebinding) then it 
would be OK.

--
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] Closures and $this

[Victor Bolshov]

Hello.

Jelrik, I could easily show a real-world example where using $this in
closures could help. Consider Person class which has to verify that
email address is unique.
Suppose we have validation code in a single place and
filter_var_array() is used to check all the data:

class Person {
  ..
  function validate()
  {
filter_var_array(array(
  'email' => array('filter' => FILTER_CALLBACK, 'callback' =>
$this->getEmailValidator())
));
  }
  private function getEmailValidator()
  {
return function($email) {
  // here, $this->id property is used, not only $email argument
}
  }
}

When $this is available in closures, everything is ok. When you don't
have $this - you end up with messy decisions like:

private function getEmailValidator()
{
  $self = $this;
  return function($email) use ($self) {
// here, $self->getId() method is used
  }
}

.. or:

function validate()
{
  filter_var_array(array(
// $this->validateEmail() should be public - breaks encapsulation
'email' => array('filter' => FILTER_CALLBACK, 'callback' =>
array($this, 'validateEmail')
  ));
}

Of course, this is a special case - but I could easily imagine
ActiveRecord class in which validation is based on a similar approach.

This is why $this in closures would be useful for me - however I
definitely would like $this not to change ever.

2009/11/19 Jelrik van Hal :
> Victor Bolshov wrote:
>>
>> Hi.
>>
>> Personally, I beleive that (A) approach is the best: "bind $this to
>> the object scope at creation" and never change it, issue error when
>> $this is used where not available. It also seems to me like this way
>> it could be implemented with better performance, am I right?
>>
>> Dynamically changing $this introduces confusion. You can use
>> $this->foo or $this->bar() inside a closure, but when $this
>> dynamically changes - you cannot be sure that "foo" property or "bar"
>> method is still there. Furthermore, dynamic approach introduces even
>> more mess when thinking about availability of private/protected class
>> members.
>>
>> Consider this code:
>>
>> class Foo {
>>  private $closure;
>>  function __construct()
>>  {
>>    /* It seems natural to me that, doing this assignment from within the
>> class,
>>       one can use private members inside the closure */
>>    $this->closure = function() { $this->privateMethod(); };
>>  }
>>  function setClosure($closure)
>>  {
>>    $this->closure = $closure;
>>  }
>>  function getClosure()
>>  {
>>    return $this->closure;
>>  }
>> }
>>
>> $foo = new Foo();
>> $foo->getClosure()->__invoke();// #CALL-1
>> $foo->setClosure(function() {
>>  /*
>>  But is it good to use private members here? It seems like it would
>> break encapsulation,
>>  and the information that the class was designed to hide - is now
>> made available in public access,
>>  although indirect.
>>  */
>>  $this->privateMethod();
>> });
>> $foo->getClosure()->__invoke();// #CALL-2
>>
>> In the end, I would like PHP to issue error when $this is used in
>> #CALL-2 but to continue working on #CALL-1.
>>
>> The (A) approach seems to me more predictable, more simple, it has
>> less information the developer needs to keep in mind when using
>> closures.
>>
>> 2009/11/17 Mathieu Suen :
>>>
>>> Chris Stockton a écrit :

 Hello,

 On Tue, Nov 17, 2009 at 2:59 AM, Mathieu Suen
  wrote:
>
> Christian Seiler a écrit :
>>
>> Hi,
>>
>> since a few months have passed since the last discussion on this topic
>> and perhaps people had time to gather some experience with the current
>> closure implementation in PHP 5.3 I'd like to restart the debate on
>> $this in closures and object extension.

 I believe that (D) wins my vote, and it convinces me twice. Once
 because I believe it is the most intuitive for users (A), and twice
 because I believe it is also the most useful (C) for users. In my
 opinion It seems the most "PHP" way.

 -Chris

>>> (D) is quite inconstant:
>>>
>>> $block = $foo->closur;
>>>
>>> $foo->closur();
>>> $block();
>>>
>>> This would produce 2 different output.
>>> For (C) here is my objection:
>>>
>>> Suppose that we are in a MVC pattern.
>>> In a controller on could do:
>>>
>>> $model->onFailDo(function () {$this->reportError()});
>>> $model->save();
>>>
>>>
>>> In the model side:
>>>
>>> public function onFailDo($block)
>>> {
>>>       $this->signalFailure = $block
>>> }
>>>
>>> public function save()
>>> {
>>>       //... Something wrong happen
>>>       return $this->signalFailure();
>>> }
>>>
>>> If you dynamically bind the $this you are obliged to treat the error
>>> reporting in the model which is not a good idea. Even worst you can't
>>> even
>>> catch up the error in the controller.
>>> It also mean that the closure is getting tightly coupled with anyone who
>>> is
>>> using it. And passing closure to different object is like spreading
>>> dependency over all the system.
>>>
>>> -- Mathieu Suen
>>>

Re: [PHP-DEV] Closures and $this

[Victor Bolshov]

Hi

> so you can with $foo->$bar() or $foo()

You're talking about variable functions/methods. But that is not the
subject of discussion. Variable functions/methods are useful but
introduce mess. This is well-known and this feature exists in PHP for
a long time - so everybody should be condidered as warned - when they
use it.

I am talking about $this->methodName() constructions. Currently, in
PHP, one can be pretty sure that if this construction works in one
place - it should work in another (I mean, methodName() will exist in
$this). To be mentioned - I'm not using variable functions here.

2009/11/19 Stanislav Malyshev :
> Hi!
>
>> If php-people really would like rebinding $this, I beleive this should
>> be done via method like Closure->bindTo() - to make the fact of
>> rebinding clear in the code.
>>
>> However, there is a problem with rebinding $this - that was not
>> mentioned yet, I think.
>
> This can be a problem, but since PHP is not a compiled language, this
> problem already exists - all method names are only checked in runtime
> anyway, so it doesn't matter if you rebind the closure or not. Of course,
> with rebinding you can easily shoot yourself in the foot by calling
> non-existing method - but so you can with $foo->$bar() or $foo() or a number
> of other ways. So I think if this construct is expressed in a way that makes
> the intent clear (i.e., no implicit rebinding) then it would be OK.
> --
> Stanislav Malyshev, Zend Software Architect
> s...@zend.com   http://www.zend.com/
> (408)253-8829   MSN: s...@zend.com
>



-- 
Regards,
Victor

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

Re: [PHP-DEV] Closures and $this

[Michael Stillwell]

On Thu, Nov 19, 2009 at 4:29 PM, Jelrik van Hal  wrote:

> Victor, I do wholeheartedly agree with you about the mess things will be
> when allowing $this to refer to different things in different contexts of
> calling the same closure (B, C and D): I think it'll prove very difficult to
> keep track of which call will end up doing exactly what in which
> environment.

I think any mechanism for rebinding $this (whether automagical or
explicit) will be too, well, weird.  I can imagine a system of
rebinding $this being both consistent and useful, but it adds too much
complexity: to understand what's going on, you not only need to
understand closures, but you need to know how they interact with PHP's
OO system, you need to know what rebinding is (it doesn't happen
anywhere else that I can think of), and you need to know how the
rebinding system works.  JavaScript's approach actually fairly
confusing--and this is despite the fact that the language has always
had it.

> Also, I'm wondering why people think there should be a $this inside a
> closure. As stated in the RFC/Wiki, closures are not thought out to be used
> alongside OO-code. Why would we want to couple them? I see the use of
> closures, but not as OO-related tools using $this. What is the problem with
> proposal (0), leaving it as it is now?

I do think it would be nice if function() use ($this) { ... } worked,
and bound $this in the same way that it bound any other variable,
instead of producing "Cannot use $this as lexical variable".  This
would eliminate the need to do:

$obj = $this;
$fn = function() use ($obj) {
  // use $obj as if it were $this
}

Was this how things used to work, before

http://wiki.php.net/rfc/closures/removal-of-this

happened?




Michael

-- 
http://beebo.org

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

Re: [PHP-DEV] Closures and $this

[Christian Seiler]

Hello again,

> Discuss away!

I'm a little disappointed by the non-outcome of this debate. Very few
people have responded and most of them seem to agree proposal (A) should
be implemented, perhaps with the additional bind/bindTo as in my
proposal and perhaps not.

The problem here is: (A) was exactly the thing that was implemented and
that people started to have a problem with as soon as the first or
second beta of PHP 5.3 was released. And because the feedback came in so
late, Lukas & Johannes decided to remove $this support from closures for
PHP 5.3 in order to be able to decide that later on.

So basically we're at the same point where we were a little more year
ago: There's an RFC for this (the semantics of $this support were
discussed in the original closures RFC!) and the people who read it on
internals@ support it. However, I predict that if we implement exactly
the semantics that the RFC proposes, we will get into the same
discussion we had with PHP 5.3 just before the release of PHP 6... (or
5.4 should there be one).

So: What now?

Regards,
Christian

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

Re: [PHP-DEV] Closures and $this

[Lukas Kahwe Smith]

On 15.12.2009, at 20:01, Christian Seiler wrote:

> Hello again,
> 
>> Discuss away!
> 
> I'm a little disappointed by the non-outcome of this debate. Very few
> people have responded and most of them seem to agree proposal (A) should
> be implemented, perhaps with the additional bind/bindTo as in my
> proposal and perhaps not.
> 
> The problem here is: (A) was exactly the thing that was implemented and
> that people started to have a problem with as soon as the first or
> second beta of PHP 5.3 was released. And because the feedback came in so
> late, Lukas & Johannes decided to remove $this support from closures for
> PHP 5.3 in order to be able to decide that later on.
> 
> So basically we're at the same point where we were a little more year
> ago: There's an RFC for this (the semantics of $this support were
> discussed in the original closures RFC!) and the people who read it on
> internals@ support it. However, I predict that if we implement exactly
> the semantics that the RFC proposes, we will get into the same
> discussion we had with PHP 5.3 just before the release of PHP 6... (or
> 5.4 should there be one).
> 
> So: What now?


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.

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] Closures and $this

[Richard Quadling]

2009/12/15 Christian Seiler :
> Hello again,
>
>> Discuss away!
>
> I'm a little disappointed by the non-outcome of this debate. Very few
> people have responded and most of them seem to agree proposal (A) should
> be implemented, perhaps with the additional bind/bindTo as in my
> proposal and perhaps not.
>
> The problem here is: (A) was exactly the thing that was implemented and
> that people started to have a problem with as soon as the first or
> second beta of PHP 5.3 was released. And because the feedback came in so
> late, Lukas & Johannes decided to remove $this support from closures for
> PHP 5.3 in order to be able to decide that later on.
>
> So basically we're at the same point where we were a little more year
> ago: There's an RFC for this (the semantics of $this support were
> discussed in the original closures RFC!) and the people who read it on
> internals@ support it. However, I predict that if we implement exactly
> the semantics that the RFC proposes, we will get into the same
> discussion we had with PHP 5.3 just before the release of PHP 6... (or
> 5.4 should there be one).
>
> So: What now?
>
> Regards,
> Christian
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

How much of a use case is binding $this to closures (personally, I
think this is quite a common usage, but I've been using JavaScript so
maybe I've got the wrong head on).

But, if there are significant technical/internal issues with regard to
binding $this to closures, what about (and I'm expecting the usual
shoot down here as I obviously know squat) NOT binding closures at all
(option 0).

Instead get traits working.

A trait (as I understand things from the rfc) from a userland
perspective seems to offer some very similar features of bound
closures. Binding a closure to an object, to all intents and purposes
extends the object with a new callable method. Traits do that too.
Completely differently - agreed - but a class with a trait has a new
method. An object with a bound closure has a new method (ish).

I know there are differences, but because it had been previously
decided to NOT include bound closures, changing that (surely only at 6
or at a BIG push 5.4 if and when) would have to be considered so not
to break BC (though I can't really see how allowing $this to be bound
would break BC as you can't bind $this at the moment).

At this late stage, is this a realistic option?

If this _IS_ an option then I'd vote for this. I'd much rather have
traits than bound closures.

Regards,

Richard.


-- 
-
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

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

Re: [PHP-DEV] Closures and $this

[la...@garfieldtech.com]

Richard Quadling wrote:


How much of a use case is binding $this to closures (personally, I
think this is quite a common usage, but I've been using JavaScript so
maybe I've got the wrong head on).

But, if there are significant technical/internal issues with regard to
binding $this to closures, what about (and I'm expecting the usual
shoot down here as I obviously know squat) NOT binding closures at all
(option 0).

Instead get traits working.


*snip*

If I recall the trait discussion properly, traits are a compile-time 
thing.  Closure binding is a run-time thing.  They are not comparable 
and one cannot really be used to implement the other.  (Well, 
hypothetically bound closures could kinda-sorta replicate traits, but it 
would be a pretty lousy way of doing it as you get no compile-time 
enforcement or interface support.)


--Larry Garfield

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

[PHP-DEV] Closures and $this: Please vote!

[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).

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

Re: [PHP-DEV] Closures and $this: Please vote!

[Stanislav Malyshev]

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)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] Closures and $this: Please vote!

[Christian Seiler]

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 this in the next few days.

Since my last posting in mid-December nobody else commented on this. My
overview back then still holds. The majority of people (internals@ and
otherwise) was in favor of (A+), so I'll implement that and put details
of the implementation and the discussion into the Wiki.

Regards,
Christian

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

Re: [PHP-DEV] Closures and $this: Please vote!

[Hannes Magnusson]

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

Preferably without any Closure->bindto black arts.

-Hannes

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

Re: [PHP-DEV] Closures and $this: Please vote!

[Stanislav Malyshev]

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 to a large object)


--
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] Closures and $this: Please vote!

[Christian Seiler]

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 want $obj->closureProp() I'd expect you to vote for
A and not A+... (If you want to stick to that it's fine, I'm just a
little stupefied.)

Regards,
Christian

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

Re: [PHP-DEV] Closures and $this: Please vote!

[Alexey Zakhlestin]

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.net/unsub.php

Re: [PHP-DEV] Closures and $this: Please vote!

[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 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).



--
Ionut G. Stan
I'm under construction  |  http://blog.igstan.ro/

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

Re: [PHP-DEV] Closures and $this: Please vote!

[Tjerk Anne Meesters]

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 world");

If that can be done with A or A+ my vote goes for either one. I don't
think rebinding will be very useful or intuitive though (unless one
would want to use it as a drop-in method for their classes).


On 12/16/09, Ionut G. Stan  wrote:
> 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 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).
>>
>
> --
> Ionut G. Stan
> I'm under construction  |  http://blog.igstan.ro/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
--
Tjerk

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

Re: [PHP-DEV] Closures and $this: Please vote!

[Richard Quadling]

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 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).
>>
>
> --
> Ionut G. Stan
> I'm under construction  |  http://blog.igstan.ro/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

(A+) +1 from a non internals voter.

-- 
-
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

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

RE: [PHP-DEV] Closures and $this: Please vote!

[Mike Robinson]

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 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

FWIW, another non-internal-dev vote for (A+).

Best Regards

Mike Robinson





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

Re: [PHP-DEV] Closures and $this: Please vote!

[Larry Garfield]

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
> > 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+)

Another non-C-developing PHP coder voting for A+.  I like the explicitness of 
knowing when $this is going to change on me, and it allows for dynamic 
extension. 

Regarding the other points noted in the RFC, I believe that when a closure is 
bound to an object it should have full access to private/protected properties 
of that object.  (I believe that is option 2.)  If that is not done, then 
being able to call $foo->aClosure() is really just syntactic sugar and not 
especially useful.  

When cloning an object with a bound closure, my expectation is that it would 
behave the same way as an object or resource that is a property of the cloned 
object.  I don't know if that makes sense in the context of closures, but that 
is what my knee-jerk expectation would be.  I am not sure we can rely on the 
__clone() method to handle rebinding the closure.  The point of binding 
closures to an object is so that objects can get extra methods post-creation.  
How can the __clone() method, which is written pre-creation, know what 
closures have been bound to it in order to rebind them to the new object?  If 
the developer knows the exact name in advance to rebind, then generally that 
code could just be a normal method.  I don't see how one could logically 
rebind a closure on __clone().

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

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

Re: [PHP-DEV] Closures and $this: Please vote!

[Joey Smith]

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 a bit torn on how clone should be addressed - there's already some things
that (IMO) have a fairly high "WTF" factor on cloning, and I'd hate to see
more of that introduced.

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

Re: [PHP-DEV] Closures and $this: Please vote!

[Victor Bolshov]

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.

Regards,
Victor

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

Re: [PHP-DEV] Closures and $this: Please vote!

[Christian Seiler]

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 bind/bindTo but no implicit
$obj->x = function () { ... } ; $obj->x(); without userland implementing
it in __call]

non-internals@ votes:

0:  (0) -
A:  (1) Victor Bolshov
C:  (0) -
D:  (0) -
A+: (4) Ionut G. Stan, Richard Quadling, Mike Robinson, Larry Garfield
AS: (0) -
---
 5 votes

Total tally:

0:   1
A:   2
C:   0
D:   0
A+:  6
AS:  1
---
10 votes

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.

Regards,
Christian

PS: As a side note, since somebody brought it up in the past few days:
It is not really *technical* issue with the engine which variant we
implement, it's simply a design choice. We didn't drop $this support in
closures in 5.3 for technical reasons but for the simple reason that
there was no agreement in sight on *how* to implement it. And since the
current code for closures is a bit of a mess in PHP6 because of the back
and forth due to the numerous discussions, I'll have to touch it again
anyway. (I only cleaned up 5.3 for the release.)

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

[PHP-DEV] What about static/self was: (Re: [PHP-DEV] Closures and $this)

[mathieu.suen]

Hi,

Also $this have been wildly discuss here, but the same discussion can be 
apply to static/self.


self might be simple to figure out how to bind within a closure.
It can be bind to the name of the class where the closure is define.

static is a more tricky one but it should be the same thing than $this.

Is there a RFC about it?
Thanks


Stanislav Malyshev wrote:

Hi!

I see that still nothing happens with closures and $this, and it 
sounds like the overall feeling was that we still want $this in 
closures work, and most are inclined to A here:

http://marc.info/?l=php-internals&m=126090656804423&w=2
or some version of it.

So, can anybody provide any reason not to resurrect $this in closures 
in trunk? If not, I intend to do it next week (unless somebody is 
already working on it - don't want to step on anybody's toes :).


-- Mathieu Suen



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

[PHP-DEV] Re: What about static/self was: (Re: [PHP-DEV] Closures and $this)

[Stanislav Malyshev]

Hi!


Also $this have been wildly discuss here, but the same discussion can be
apply to static/self.

self might be simple to figure out how to bind within a closure.
It can be bind to the name of the class where the closure is define.


I would guess self binds to the scope, and static binds to the called 
scope (though in the case of closure it'd probably be the same?), but 
I'll check it and add some tests for it. Thanks for bringing this up, 
this is indeed something that wasn't covered before.



Is there a RFC about it?


There is the RFC about closure object support, but I don't think these 
matters were covered there.

--
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