Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hi!
function replace_spaces ($text) {
static $replacement = function ($matches) {
return str_replace ($matches[1], ' ', 'nbsp;').' ';
};
return preg_replace_callback ('/( +) /', $replacement, $text);
}
That is using static would result in creating the function only once.
I'm not sure this exactly one would work, as closure is not a constant
expression and thus its use as initializer may not work. However,
converting it to pseudo-singleton may work:
static $replacement = null;
if($replaceement == null) {
$replacement = function { blah-blah }
}
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hello Christian,
cool progress and nice syntax. The only thing I was wondering of is
whether the following would work:
function replace_spaces ($text) {
static $replacement = function ($matches) {
return str_replace ($matches[1], ' ', 'nbsp;').' ';
};
return preg_replace_callback ('/( +) /', $replacement, $text);
}
That is using static would result in creating the function only once.
marcus
p.s.: Given the current state, my take is put it in and finish the last
two or three edgecases while namespace and GC mature. Actually we still
haven't had the namespace syntax decision. All thta happened there was we
will apply the patch as is and when it is done we'll discuss. Now when the
namespaces were said to be ready someone just put the discussion down.
Clever politics. However namespaces are imo far from being finished.
Either way this feature is lkimited enough, stable enough, agreed up-on
enough and gives something a lot of people were waiting for. Let's do it
now. PHP 6 even when focused on will come with another ton of major new
features. That is unicode, still pretty much untested. Also there are
traits waiting and then we might want to have the taint model. Personally
given it's last state of 1% slowdown I really want it. So put all together
we should avoid 5.4 and put smaller features into 5.3 and once we're out
with 5.3.1 we should close 5.2 branch, only apply fixes and security
issues to 5.3 and get 6 in a working state.
marcus
Wednesday, July 2, 2008, 1:41:20 PM, you wrote:
Hi,
After some discussion with Dmitry, he and I have continued to improve
the current closure patch. You can find the current proposal with
patches for 5_3 and HEAD here:
http://wiki.php.net/rfc/closures
(Please read it again, I've changed quite a lot.)
Basically, it's the syntax with use ($lexical) in the function
declaration, optional references, optional static keyword for functions
that don't need $this and support for __invoke. I know that there was
some disagreement on the syntax (including by me) but I think this is
the best compromise we can achieve while still staying consistent with
PHPs current semantics and not breaking BC at all.
I've spoken to Dmitry and he said the patch will be committed to HEAD
soon. Since both Dmitry and I still want to have it in 5_3 too, we'd
want to ask for opinions on this again - especially since after quite a
lot of thorough review and discussion on this list basically all the
side-effects have been addressed and there are now quite a few tests
that ensure the correct behaviour of closures. Also, the patch is now
built in a way that the main functionality remains inside
zend_closures.c, so any possible not yet encountered bug can be fixed
without breaking binary compability.
Regards,
Christian
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hi,
On Thu, 2008-07-03 at 22:30 +0400, Dmitry Stogov wrote:
I don't see big problems with closures. The patch is simple and
stable.
It's main part isolated in zend_closures.c and it doesn't affect other
parts of engine.
Changes too the languages always introduce some side effects and
therefore we have too be careful there. Even stuff which is from engine
point of view nice might have some effects on the userland which might
not be too nice, just see the ongoing discussions about details about
namespaces... But back to closures:
I spent the last weeks with less mail reading and am still 112 mails on
internals behind so maybe I missed something there but even short tests
showed me things which might need cleanup:
A tiny thing I saw is different naming in different places:
php -r 'is_callable((function () {}), true, $name); var_dump($name);'
string(6) lambda
vs.
php -r 'var_dump(function(){});'
object(Closure)#1 (0) {
}
Do we really want to use both names in userland? Is a string lamda
really the best represantation for callable_name? (this might even be an
issue if somwbody has a function called lambda ... for whatever reason,
oh just checked people even do:
http://google.com/codesearch?hl=enlr=q=lang%3Aphp+%22Function+lambda(%
22sbtn=Search )
Another issue I found during my short testing period today is
reflection: In a previous position I had to deal with callbacks, for
making the code more robust I checked the callback using reflection
before accepting it, the code looks something like that:
function setCallback($cb) {
if (is_array($cb) {
$r = new ReflectionMethod($cb);
} elseif (is_String($cb)) {
$r = new ReflectionFunction($cb);
} else {
throw new Exception();
}
if ($r-getNumberOfRequiredParameters() != 2) {
throw new Exception();
}
/* ... morre checks of that kind ... */
}
Now such a check isn't possible, all reflection information on the
callback I can get is that it is an object of type Closure having a
method __invoke() with zero required parameters. There's no further
information on the function, so probably we need a ReflectionClosure
class or something
Both of them are tiny issues which can be fixed in a quite simple way
(or be documented as expected) but my concern is that we'll find way
more of them.
So the final question is: Do we want to go in a higher pace to get
things out and have other features ready which can be added early for a
new release cycle or do we want to go a bit slower with the risk of
stopping and probably going backwards, again.
I'd prefer the first way (even so I do really like closures and wanted
to have them for some lng time...)
I expect more problems with GC
GC can be problematic yes, but imo gc can either be disabled by default
and documented as use only with care for running your unit test suite
or completely dropped, even in a later stage if there are problems, I
don't see there much potential for long going detail discussions. Even
if it's, technically, more critical.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hi Johannes, Am Freitag, den 04.07.2008, 11:18 +0200 schrieb Johannes Schlüter: Now such a check isn't possible, all reflection information on the callback I can get is that it is an object of type Closure having a method __invoke() with zero required parameters. There's no further information on the function, so probably we need a ReflectionClosure class or something Couldn't ReflectionFunction play that role. Classes and instances with a defined __invoke method can be reflected with ReflectionFunction? cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
On Fri, 2008-07-04 at 11:31 +0200, Lars Strojny wrote:
Hi Johannes,
Am Freitag, den 04.07.2008, 11:18 +0200 schrieb Johannes Schlüter:
Now such a check isn't possible, all reflection information on the
callback I can get is that it is an object of type Closure having a
method __invoke() with zero required parameters. There's no further
information on the function, so probably we need a ReflectionClosure
class or something
Couldn't ReflectionFunction play that role. Classes and instances with a
defined __invoke method can be reflected with ReflectionFunction?
At the moment: not enough.
$ php -r 'echo new ReflectionObject(function ($a, $b) use ($c) {});'
Object of class [ internal final class Closure ] {
- Constants [0] {
}
- Static properties [0] {
}
- Static methods [0] {
}
- Properties [0] {
}
- Dynamic properties [0] {
}
- Methods [1] {
Method [ internal public method __invoke ] {
}
}
}
it's not mentioning the parameters or the used variable, and yes, it's a
tiny issue which can, most likely, fixed within an hour or so but I
guess we'll have many more of that kind: Tiny issues which end up in
discussions about taste (should we add a new class or simply add
special treatment in ReflectionMethod for Closure::__invoke?) and all
this stuff can delay things... That's the risk I'm seeing.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
On Thu, Jul 03, 2008 at 10:30:43PM +0400, Dmitry Stogov wrote: I don't see big problems with closures. The patch is simple and stable. While you're probably right, it seems there is still lots of discussion about how closures should work. It seems better to get this right in a later version than to jam it in 5.3 just because it will be out sooner. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hi Lukas, From my point of view the proposed closures concept is very consistent and implementation doesn't complicate the engine at all. The code without closures will work without any changes, but code with closures (instead of eval() and create_function()) will work significant faster as lambda function will be stored in opcode caches. Opcode caches don't even need to be modified to do that. BTW: I see you point of view and it makes sense. It's just pity that we will need to wait for closures additional year(s). Thanks. Dmitry. Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
On Wed, 2 Jul 2008, Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. Actually, we should forget about 5.4 and focus on 6.0 instead. It has been lingering for waay to long now. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
Derick Rethans wrote: On Wed, 2 Jul 2008, Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. Actually, we should forget about 5.4 and focus on 6.0 instead. It has been lingering for waay to long now. YES PLEASE -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
Absolutely agree. I don't see any reason for 5.4. We don't plan any significant new features. Thanks. Dmitry. Derick Rethans wrote: On Wed, 2 Jul 2008, Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. Actually, we should forget about 5.4 and focus on 6.0 instead. It has been lingering for waay to long now. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
On 03.07.2008, at 10:34, Dmitry Stogov wrote: Absolutely agree. I don't see any reason for 5.4. We don't plan any significant new features. You guys are scaring me .. I was hoping to evade such discussions. PHP 5.3 is probably the minor version release with the most major changes ever. Mostly because we waited too long to go into release mode. PHP 6 has of course lingered even longer and it really really needs to get out the door ASAP. Now what I would propose is that we go into release mode on PHP 6 as well. Due to the nature of it being a major version bump it will naturally take longer to get completed. Depending on how quickly we move with PHP 5.3, we will then either release a PHP 5.4 with all of the open items before PHP 6 or more or less at the same time. But if we put the burden of being the last planned PHP 5 release onto 5.3, we will have huge issues getting it out the door. So please let us keep 5.4 on the table, but at the same time do everything we can to get PHP 6 onto some sort of release schedule. I have emailed Andrei about this offlist when I saw Derick's email. But I just wanted to send this email as a sort of damage control :) regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
On Jul 3, 2008, at 4:41 AM, Lukas Kahwe Smith wrote: Absolutely agree. I don't see any reason for 5.4. We don't plan any significant new features. You guys are scaring me .. I was hoping to evade such discussions. PHP 5.3 is probably the minor version release with the most major changes ever. Mostly because we waited too long to go into release mode. PHP 6 has of course lingered even longer and it really really needs to get out the door ASAP. Now what I would propose is that we go into release mode on PHP 6 as well. Due to the nature of it being a major version bump it will naturally take longer to get completed. Depending on how quickly we move with PHP 5.3, we will then either release a PHP 5.4 with all of the open items before PHP 6 or more or less at the same time. But if we put the burden of being the last planned PHP 5 release onto 5.3, we will have huge issues getting it out the door. So please let us keep 5.4 on the table, but at the same time do everything we can to get PHP 6 onto some sort of release schedule. I have emailed Andrei about this offlist when I saw Derick's email. But I just wanted to send this email as a sort of damage control :) A loud +1 to this from me. Can we get an RFC into the Wiki on this? -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hi, 1) The RFC page says that closures pass by value by default. Although it is not stated, am I correct in saying that due to the way resources and objects (and presumably therefore lambdas) are handled they will still have the effect of passing by reference anyway, just as with a function parameter? Yes, of course. :) 2) It is unclear from the RFC if static class closures (I am not fond of that syntax, I grant) are the only ones that won't import $this. Is the suggested detection optimization not included, and therefore it's up to the programmer to avoid dangling references that keep stray classes around? It's up to the programmer for now, static = no $this, no static = $this. 3) Can __invoke() accept parameters, Yes. 4) The ability to reflect and then call a function or method as a closure sounds highly nifty. However, I am unclear on why it is necessary to pass in the $this to use. In that case, wouldn't it make more sense to use ReflectionObject() in the first place so that the $this is implicitly known? Probably. But if we start picking on every detail of the patch until it is absolutely perfect, it will never get committed, not even to HEAD. So I propose that it should be committed to HEAD (as long as there are no major objections) and then worry about tiny details afterwards. 5) There's a couple spelling and grammar errors. :-) Feel free to correct them if you have access to the wiki. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Closures: updated proposal and patch
I think given closures is in a pretty fully baked state (we had an exemplary process) the main questions to ask are: a) Assuming we are going through numerous beta and RC cycles for PHP 5.3, do we think that the time it would take for other features like namespaces, garbage collector to be fully tested and stabilize would allow for closures to stabilize too in that same time frame (i.e. would not push out a final release date for PHP 5.3)? b) Are the release managers willing to manage an additional major feature as part of the release process? I am not stating my opinion here because I could go either way although ultimately my bias is not to postpone a feature freeze nor a final release so it's really up to the release managers to decide on (1) and (2). Andi -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 12:27 AM To: Lukas Kahwe Smith Cc: Christian Seiler; php-dev List Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch Hi Lukas, From my point of view the proposed closures concept is very consistent and implementation doesn't complicate the engine at all. The code without closures will work without any changes, but code with closures (instead of eval() and create_function()) will work significant faster as lambda function will be stored in opcode caches. Opcode caches don't even need to be modified to do that. BTW: I see you point of view and it makes sense. It's just pity that we will need to wait for closures additional year(s). Thanks. Dmitry. Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
I don't see big problems with closures. The patch is simple and stable. It's main part isolated in zend_closures.c and it doesn't affect other parts of engine. I expect more problems with GC Thanks. Dmitry. Andi Gutmans wrote: I think given closures is in a pretty fully baked state (we had an exemplary process) the main questions to ask are: a) Assuming we are going through numerous beta and RC cycles for PHP 5.3, do we think that the time it would take for other features like namespaces, garbage collector to be fully tested and stabilize would allow for closures to stabilize too in that same time frame (i.e. would not push out a final release date for PHP 5.3)? b) Are the release managers willing to manage an additional major feature as part of the release process? I am not stating my opinion here because I could go either way although ultimately my bias is not to postpone a feature freeze nor a final release so it's really up to the release managers to decide on (1) and (2). Andi -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 12:27 AM To: Lukas Kahwe Smith Cc: Christian Seiler; php-dev List Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch Hi Lukas, From my point of view the proposed closures concept is very consistent and implementation doesn't complicate the engine at all. The code without closures will work without any changes, but code with closures (instead of eval() and create_function()) will work significant faster as lambda function will be stored in opcode caches. Opcode caches don't even need to be modified to do that. BTW: I see you point of view and it makes sense. It's just pity that we will need to wait for closures additional year(s). Thanks. Dmitry. Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
Given the 5.3 is not yet out (even as a Beta) I think discussing 5.4 is way way premature. For now I think 5.3 is close enough to 6 in feature set to not warrant 5.4. I think the effort at this point should be spent on getting 5.3 out and figuring out how to proceed with PHP 6. On 3-Jul-08, at 4:06 AM, Derick Rethans wrote: On Wed, 2 Jul 2008, Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. Actually, we should forget about 5.4 and focus on 6.0 instead. It has been lingering for waay to long now. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Looking through the closures patch, I would tend to agree. GC has certainly caused us way more headaches in APC-land than closures will, from the looks of it. -Rasmus Dmitry Stogov wrote: I don't see big problems with closures. The patch is simple and stable. It's main part isolated in zend_closures.c and it doesn't affect other parts of engine. I expect more problems with GC Thanks. Dmitry. Andi Gutmans wrote: I think given closures is in a pretty fully baked state (we had an exemplary process) the main questions to ask are: a) Assuming we are going through numerous beta and RC cycles for PHP 5.3, do we think that the time it would take for other features like namespaces, garbage collector to be fully tested and stabilize would allow for closures to stabilize too in that same time frame (i.e. would not push out a final release date for PHP 5.3)? b) Are the release managers willing to manage an additional major feature as part of the release process? I am not stating my opinion here because I could go either way although ultimately my bias is not to postpone a feature freeze nor a final release so it's really up to the release managers to decide on (1) and (2). Andi -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 12:27 AM To: Lukas Kahwe Smith Cc: Christian Seiler; php-dev List Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch Hi Lukas, From my point of view the proposed closures concept is very consistent and implementation doesn't complicate the engine at all. The code without closures will work without any changes, but code with closures (instead of eval() and create_function()) will work significant faster as lambda function will be stored in opcode caches. Opcode caches don't even need to be modified to do that. BTW: I see you point of view and it makes sense. It's just pity that we will need to wait for closures additional year(s). Thanks. Dmitry. Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
On Thu, 03 Jul 2008 11:06:48 +0200, Christian Seiler [EMAIL PROTECTED] wrote: Hi, 1) The RFC page says that closures pass by value by default. Although it is not stated, am I correct in saying that due to the way resources and objects (and presumably therefore lambdas) are handled they will still have the effect of passing by reference anyway, just as with a function parameter? Yes, of course. :) Just making sure. :-) 2) It is unclear from the RFC if static class closures (I am not fond of that syntax, I grant) are the only ones that won't import $this. Is the suggested detection optimization not included, and therefore it's up to the programmer to avoid dangling references that keep stray classes around? It's up to the programmer for now, static = no $this, no static = $this. Hm. I defer to those who understand the guts of the engine on whether that's a good call or not. If left as is then the user docs should be very clear about the potential for memory issues there, since most lambas I suspect will not need a $this, even if they happen to be defined within a method. 3) Can __invoke() accept parameters, Yes. Neato. That should also be included in the user-side docs. 4) The ability to reflect and then call a function or method as a closure sounds highly nifty. However, I am unclear on why it is necessary to pass in the $this to use. In that case, wouldn't it make more sense to use ReflectionObject() in the first place so that the $this is implicitly known? Probably. But if we start picking on every detail of the patch until it is absolutely perfect, it will never get committed, not even to HEAD. So I propose that it should be committed to HEAD (as long as there are no major objections) and then worry about tiny details afterwards. As a rank-and-file PHP developer, I have no major objections remaining that aren't bikeshed questions. :-) (And I certainly understand the desire to get the base committed and polish/extend in follow-up patches, as I am doing so myself on another project.) 5) There's a couple spelling and grammar errors. :-) Feel free to correct them if you have access to the wiki. I do not believe I do. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hi!
Re-reading the proposal, I encountered something unexpected:
$replacer = $example-getReplacer ('goodbye');
echo $replacer ('hello world'); // goodbye world
$replacer-setSearch ('world');
echo $replacer ('hello world'); // hello goodbye
Does it mean closure would forward all method calls to it to the
enclosed object? Not sure if it's a good idea - seems too magical. Maybe
we need to be more explicit, something like
$replacer-getThis()-setSearch('world')? I.e., if you have object of
type Closure, you can't actually know what methods it has - it'd depend
on $this inside, which we don't have access to right now. That seems
kind of strange.
Or did you just mean $example-setSearch() and I'm worried about
nothing? :) In this case, I'd just propose to have getThis() anyway.
Except for that - excellent work!
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hi Stanislav, Or did you just mean $example-setSearch() and I'm worried about nothing? :) Yes, absolutely, Sorry for the confusion caused. ;-) I fixed that in the Wiki. In this case, I'd just propose to have getThis() anyway. I don't see a need, but I'm not against it. Should be extremely trivial to implement. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
On Wednesday 02 July 2008 6:41:20 am Christian Seiler wrote:
Hi,
After some discussion with Dmitry, he and I have continued to improve
the current closure patch. You can find the current proposal with
patches for 5_3 and HEAD here:
http://wiki.php.net/rfc/closures
(Please read it again, I've changed quite a lot.)
Basically, it's the syntax with use ($lexical) in the function
declaration, optional references, optional static keyword for functions
that don't need $this and support for __invoke. I know that there was
some disagreement on the syntax (including by me) but I think this is
the best compromise we can achieve while still staying consistent with
PHPs current semantics and not breaking BC at all.
I've spoken to Dmitry and he said the patch will be committed to HEAD
soon. Since both Dmitry and I still want to have it in 5_3 too, we'd
want to ask for opinions on this again - especially since after quite a
lot of thorough review and discussion on this list basically all the
side-effects have been addressed and there are now quite a few tests
that ensure the correct behaviour of closures. Also, the patch is now
built in a way that the main functionality remains inside
zend_closures.c, so any possible not yet encountered bug can be fixed
without breaking binary compability.
Regards,
Christian
Questions:
1) The RFC page says that closures pass by value by default. Although it is
not stated, am I correct in saying that due to the way resources and objects
(and presumably therefore lambdas) are handled they will still have the
effect of passing by reference anyway, just as with a function parameter?
2) It is unclear from the RFC if static class closures (I am not fond of that
syntax, I grant) are the only ones that won't import $this. Is the suggested
detection optimization not included, and therefore it's up to the programmer
to avoid dangling references that keep stray classes around? Or is the
engine going to be smart about that, static keyword or no?
3) Can __invoke() accept parameters, or is it an empty param list only? (I
suppose I can see arguments either way here; I just don't know what the
current implementation does.)
4) The ability to reflect and then call a function or method as a closure
sounds highly nifty. However, I am unclear on why it is necessary to pass in
the $this to use. In that case, wouldn't it make more sense to use
ReflectionObject() in the first place so that the $this is implicitly known?
$object = new Example;
$r = new ReflectionObject($object);
$method = $r-getMethod('printer');
$closure = $method-getClosure ();
$closure();
5) There's a couple spelling and grammar errors. :-)
--
Larry Garfield
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
