Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38335 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54514 invoked from network); 17 Jun 2008 21:04:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Jun 2008 21:04:13 -0000 Authentication-Results: pb1.pair.com header.from=chris_se@gmx.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=chris_se@gmx.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.net designates 213.165.64.20 as permitted sender) X-PHP-List-Original-Sender: chris_se@gmx.net X-Host-Fingerprint: 213.165.64.20 mail.gmx.net Received: from [213.165.64.20] ([213.165.64.20:46564] helo=mail.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 06/6B-24906-C0228584 for ; Tue, 17 Jun 2008 16:43:57 -0400 Received: (qmail invoked by alias); 17 Jun 2008 20:43:52 -0000 Received: from p54A173C3.dip.t-dialin.net (EHLO chris-se.dyndns.org) [84.161.115.195] by mail.gmx.net (mp067) with SMTP; 17 Jun 2008 22:43:52 +0200 X-Authenticated: #186999 X-Provags-ID: V01U2FsdGVkX186KFYhhxc6JJEzsGLe6mhiGzlNAc7kiZq8YpZXWd AoxcUhlCKst8kW Received: from [192.168.0.175] (HSI-KBW-091-089-005-213.hsi2.kabelbw.de [91.89.5.213]) by chris-se.dyndns.org (Postfix) with ESMTP id C670310506; Tue, 17 Jun 2008 22:33:17 +0200 (CEST) Message-ID: <485821D6.7020604@gmx.net> Date: Tue, 17 Jun 2008 22:43:02 +0200 User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lars Strojny CC: Stanislav Malyshev , Marcus Boerger , Johannes Schlueter , php-dev List References: <4856A547.3080801@gmx.net> <1961603263.20080617120320@marcus-boerger.de> <4857ACE1.3050501@gmx.net> <1178748433.20080617211038@marcus-boerger.de> <48580E5C.9090100@zend.com> <1213732325.21878.9.camel@localhost> In-Reply-To: <1213732325.21878.9.camel@localhost> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP From: chris_se@gmx.net (Christian Seiler) Hi! >> I'm not Johannes and I didn't review the proposal in detail yet, but I >> think we have enough for 5.3 right now. I'd think we better concentrate >> on tying the loose ends and rolling beta out and then moving towards the >> release than adding more and more features and never releasing it. 5.3 >> is not the final release until the end of times, there will be 5.4 etc. >> and 6, so there will be ample opportunity to add stuff. And 5.3 has >> enough stuff to be released, there's no rush to add more new things, >> especially radically new ones. My opinion is that we better take some >> time with it and not tie it to 5.3. > > I would like to see 5.3 released first before we add really cool > features like this. I'm really +1 for closures but I please for 5.4 and > 6. If I may add my own personal (and biased ;-)) opinion (which may not count much but I'd like to present the arguments): I'd like to see it in PHP 5.3. Mainly because of two reasons: First: My patch is quite non-intrusive, it only adds things in a few places (new opcode, a few checks). If you only look at the non-generated files (i.e. excluding files generated by re2c or zend_vm_gen.php), the patch is actually not even that long: http://www.christian-seiler.de/temp/closures-php-5.3-2008-06-17-3-redux.diff Except for the introduction of a 'lexical' keyword I carefully designed the patch not to have *any* impact *at all* on PHPs other behaviour. I'd be genuinely surprised if any code breaks with my patch. I also don't see how this would delay 5.3 - of course things have to be tested but at least as far as I can tell the major showstoppers currently are class inheritance rules and namespaces which still cause quite a few headaches of their own. Second: If closures are not supported in PHP 5.3, even with the release of PHP 6 backwards compability will be a hindrance in using them. Since PHP 6 will have Unicode support and thus quite a few semantic changes, this will of course not matter much for the actual PHP applications since these will have to change anyway. But think of class libraries: There are many things that can be implemented in class libraries where unicode support doesn't matter at all - such as for example advanced date and time calculations (beyond timelib), financial calculations etc. Such libraries will probably want to maintain compability with PHP 5.3 as long as possible. But these libraries may profit from closures. If you still decide to include closures only from post PHP 5.3, I suggest to at least declare 'lexical' a reserved keyword in PHP 5.3. Just my 2 cents... As to the patch for HEAD: I thought it best to wait for unicode.semantics to go away along with the if (UG(unicode)) checks before implementing it (everything else would be a waste of time - since if I'm not mistaken someone is actually currently removing those). If I really am mistaken in my interpretation of the discussions here on this topic and they are not going away (at least not in the short term), I can of course provide one now (meaning the next few days). Regards, Christian