Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73020 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92282 invoked from network); 9 Mar 2014 05:41:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2014 05:41:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.91 smtp91.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.91] ([108.166.43.91:58548] helo=smtp91.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 74/60-18839-5FEFB135 for ; Sun, 09 Mar 2014 00:41:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 22AA8140A73; Sun, 9 Mar 2014 00:41:07 -0500 (EST) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id C1DB8140935; Sun, 9 Mar 2014 00:41:06 -0500 (EST) Message-ID: <531BFEF1.5000305@sugarcrm.com> Date: Sat, 08 Mar 2014 21:41:05 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Marco Schuster , internals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Idea: ifdef-like feature to ease userland BC From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > especially with (radical) userland API changes coming up in PHP6, > might I suggest something like a ifdef feature which turns blocks of > code into comments? How is it supposed to be implemented? PHP has no separate "compile-time" than can produce significant improvement in performance, like C-like languages do, and given opcode caching, such conditions should either be resolved statically - which means limited usability, as you'd have to drive them off something that you can use no code to define, or use some logic to resolve them dynamically, which logic would probably take nearly as much time and space as regular if() would. > This would allow framework authors to provide backwards compatibility > with "older" PHP versions while being able to take advantage of new > PHP features. This can easily be done by a set of includes and using version checks, function_exists, class_exists and such. The performance hit in case those are not needed would be very minimal and probably not warranting new language construct addition. > In theory, it could also be supplied as "update" to the already > existing minor versions (5.4,5.5 and 5.6) so that these versions can > also use the new code. Not likely for stable ones. According to our release process, we do not add language features in old stable versions, and the additions are limited to bugfixes and small self-contained features. Adding such feature would hardly qualify as one of those. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227