Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68541 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64545 invoked from network); 15 Aug 2013 23:42:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Aug 2013 23:42:22 -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:52045] helo=smtp91.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1B/0B-06453-E576D025 for ; Thu, 15 Aug 2013 19:42:22 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id ED96114009D; Thu, 15 Aug 2013 19:42:18 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 0BDCC1400D6; Thu, 15 Aug 2013 19:42:16 -0400 (EDT) Message-ID: <520D6758.4050500@sugarcrm.com> Date: Thu, 15 Aug 2013 16:42:16 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sara Golemon CC: Derick Rethans , Anthony Ferrara , Sebastian Krebs , Julien Pauli , "internals@lists.php.net" References: <520B4772.8090701@sugarcrm.com> <520BBA89.1090208@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Constant Scalar Expressions From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Though obv, in reality we wouldn't use runkit_constant_add(), it'd be a > new opcode which had the same effect. This is basically transparent to > opcode caches, allows the constant to actually change based on runtime If the class definition can actually change at runtime, I think it'd make it much harder for opcode caches since they can't any longer assume class definition can't change at any random place in the code. But this is not the most tricky part. The most tricky part is this: if(true) return; class Foo { const halfpie = M_PI/2; } Now what happens if this is implemented as an opcode? We can't run any opcodes past return statement, but Foo is expected to be defined here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227