Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54115 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50011 invoked from network); 21 Jul 2011 01:27:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jul 2011 01:27:25 -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 67.192.241.143 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.143 smtp143.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.143] ([67.192.241.143:47870] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 63/E0-39763-C70872E4 for ; Wed, 20 Jul 2011 21:27:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B5DA518027C; Wed, 20 Jul 2011 21:27:20 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 7C7051801E5; Wed, 20 Jul 2011 21:27:20 -0400 (EDT) Message-ID: <4E278078.5000809@sugarcrm.com> Date: Wed, 20 Jul 2011 18:27:20 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "RQuadling@GMail.com" CC: PHP internals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Coding for the differences in 5.3 and 5.4 _zend_class_entry structure. From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 7/20/11 4:25 AM, Richard Quadling wrote: > As several extensions have had to implement these #defines to > distinguish between the different zend engine versions, should these > "level playing field" macros be moved (and completed) form the > extension to core? If you're talking about ZEND_CE_FILENAME and similar ones, we could add it into 5.4, but we couldn't retroactively add it to existing PHP sources, so you'd have to ifdef in your extension anyway. At which point adding it into 5.4 becomes kind of useless. So if you have any idea of how that would be useful please explain. If you're talking about ZEND_ENGINE_2_4 macro, we could have it, though ZEND_MODULE_API_NO is more precise and safe to use. The problem is now that many modules have added it, adding it in core would actually make those modules issue warnings, so I'm not sure we actually should do it :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227