# [RFC] Closures: updated proposal and patch - Thread: https://externals.io/message/38700 - Original archive: https://news-web.php.net/php.internals/38700 - Started by Christian Seiler on 2008-07-02T11:41:20+00:00 - Messages: 24 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #38700 — Christian Seiler — 2008-07-02T11:41:20+00:00 URL: https://externals.io/message/38700#38700 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 --- ## #38703 — Stanislav Malyshev — 2008-07-02T17:30:05+00:00 URL: https://externals.io/message/38700#38703 · In reply to: #38700 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 stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #38704 — Christian Seiler — 2008-07-02T17:37:00+00:00 URL: https://externals.io/message/38700#38704 · In reply to: #38703 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 --- ## #38708 — Lukas Kahwe Smith — 2008-07-02T20:18:12+00:00 URL: https://externals.io/message/38700#38708 · In reply to: #38700 > 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 mls@pooteeweet.org --- ## #38717 — Larry Garfield — 2008-07-03T01:13:13+00:00 URL: https://externals.io/message/38700#38717 · In reply to: #38700 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 larry@garfieldtech.com --- ## #38721 — Dmitry Stogov — 2008-07-03T07:27:27+00:00 URL: https://externals.io/message/38700#38721 · In reply to: #38708 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: > > > > > […] > > > 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 > mls@pooteeweet.org --- ## #38725 — Derick Rethans — 2008-07-03T08:06:07+00:00 URL: https://externals.io/message/38700#38725 · In reply to: #38708 > > > 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 --- ## #38726 — Lester Caine — 2008-07-03T08:12:55+00:00 URL: https://externals.io/message/38700#38726 · In reply to: #38725 Derick Rethans wrote: > > > > […] > > 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 --- ## #38727 — Dmitry Stogov — 2008-07-03T08:34:47+00:00 URL: https://externals.io/message/38700#38727 · In reply to: #38725 Absolutely agree. I don't see any reason for 5.4. We don't plan any significant new features. Thanks. Dmitry. Derick Rethans wrote: > > > > […] > > Actually, we should forget about 5.4 and focus on 6.0 instead. It has > been lingering for waay to long now. > > regards, > Derick --- ## #38728 — Lukas Kahwe Smith — 2008-07-03T08:41:20+00:00 URL: https://externals.io/message/38700#38728 · In reply to: #38727 > 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 mls@pooteeweet.org --- ## #38729 — Gwynne Raskind — 2008-07-03T08:47:09+00:00 URL: https://externals.io/message/38700#38729 · In reply to: #38728 > > […] > 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." --- ## #38731 — Christian Seiler — 2008-07-03T09:06:48+00:00 URL: https://externals.io/message/38700#38731 · In reply to: #38717 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 --- ## #38732 — Keryx Web — 2008-07-03T09:30:28+00:00 URL: https://externals.io/message/38700#38732 · In reply to: #38728 Lukas Kahwe Smith skrev: > 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". Let me see if I get this. PHP 5.4 = 6.0 without Unicode. PHP 6.0 = 5.4 plus Unicode. It sounds like PHP 5.4 is actually needed when 6.0 no longer has the Unicode semantics on/off switch. FWIW, personally, I need Unicode more than I need namespaces; I need Unicode more than I need traits; I need Unicode more than I need lambda and closures. I need Unicode more than I need {$capability_of_choice}. All of those things are nice, but Unicode is getting *critical*. Lars Gunther --- ## #38736 — Andi Gutmans — 2008-07-03T17:23:36+00:00 URL: https://externals.io/message/38700#38736 · In reply to: #38721 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:dmitry@zend.com] > 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: > > […] HEAD > > […] we'd > > […] quite a > > […] the > > […] tests > > […] now > > […] fixed > > […] feature > > […] of > > […] to > > […] some > > […] cool > > […] as > > […] --- ## #38737 — Arvids Godjuks — 2008-07-03T18:23:01+00:00 URL: https://externals.io/message/38700#38737 · In reply to: #38732 +1 from me - unicode is very very needed indeed. Normaly on every project I have to deal with 3 languages - english, russian and latvian - and there is no fun in making advanced html/bbcode parser (not based on str_replace or preg_replace - it is far more complex than that) using mb_string functions. 2008/7/3 Keryx Web : > Lukas Kahwe Smith skrev: > > > […] > > Let me see if I get this. > > PHP 5.4 = 6.0 without Unicode. > PHP 6.0 = 5.4 plus Unicode. > > It sounds like PHP 5.4 is actually needed when 6.0 no longer has the > Unicode semantics on/off switch. > > FWIW, personally, I need Unicode more than I need namespaces; I need > Unicode more than I need traits; I need Unicode more than I need lambda and > closures. I need Unicode more than I need {$capability_of_choice}. All of > those things are nice, but Unicode is getting *critical*. > > > Lars Gunther --- ## #38738 — Dmitry Stogov — 2008-07-03T18:30:43+00:00 URL: https://externals.io/message/38700#38738 · In reply to: #38736 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 > > > […] > don't > > […] > we > > […] > HEAD > > […] > we'd > > […] > quite a > > […] > the > > […] > tests > > […] > now > > […] > fixed > > […] > feature > > […] > of > > […] > to > > […] > some > > […] > cool > > […] > as > > […] --- ## #38739 — Ilia Alshanetsky — 2008-07-03T18:32:03+00:00 URL: https://externals.io/message/38700#38739 · In reply to: #38725 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. > > > > […] > > 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 > > -- > > > Ilia Alshanetsky --- ## #38740 — Rasmus Lerdorf — 2008-07-03T18:33:19+00:00 URL: https://externals.io/message/38700#38740 · In reply to: #38738 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: > > […] --- ## #38756 — johannes@php.net — 2008-07-04T09:18:08+00:00 URL: https://externals.io/message/38700#38756 · In reply to: #38738 Hi, > 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=en&lr=&q=lang%3Aphp+%22Function+lambda(% 22&sbtn=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 loooong 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 --- ## #38759 — Lars Strojny — 2008-07-04T09:31:46+00:00 URL: https://externals.io/message/38700#38759 · In reply to: #38756 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 --- ## #38764 — johannes@php.net — 2008-07-04T11:42:03+00:00 URL: https://externals.io/message/38700#38764 · In reply to: #38759 > Hi Johannes, > > Am Freitag, den 04.07.2008, 11:18 +0200 schrieb Johannes Schlüter: > > […] > > 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 [ final class Closure ] { - Constants [0] { } - Static properties [0] { } - Static methods [0] { } - Properties [0] { } - Dynamic properties [0] { } - Methods [1] { Method [ 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 --- ## #38771 — Daniel Convissor — 2008-07-04T17:34:53+00:00 URL: https://externals.io/message/38700#38771 · In reply to: #38738 > 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 --- ## #38780 — Marcus Boerger — 2008-07-05T19:50:06+00:00 URL: https://externals.io/message/38700#38780 · In reply to: #38700 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], ' ', ' ').' '; }; 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 --- ## #38797 — Stanislav Malyshev — 2008-07-07T04:19:36+00:00 URL: https://externals.io/message/38700#38797 · In reply to: #38780 Hi! > function replace_spaces ($text) { > static $replacement = function ($matches) { > return str_replace ($matches[1], ' ', ' ').' '; > }; > 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 stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com