Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:43913 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77186 invoked from network); 12 May 2009 18:24:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 May 2009 18:24:17 -0000 Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.116 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 63.205.162.116 us-gw1.zend.com Windows 2000 SP4, XP SP1 Received: from [63.205.162.116] ([63.205.162.116:56934] helo=us-gw1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 59/A7-64369-0DEB90A4 for ; Tue, 12 May 2009 14:24:17 -0400 Received: from [192.168.16.83] ([192.168.16.83]) by us-gw1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 May 2009 11:24:18 -0700 Message-ID: <4A09BECD.3000602@zend.com> Date: Tue, 12 May 2009 11:24:13 -0700 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Paul Biggar CC: Guilherme Blanco , Dmitry Stogov , Marcus Boerger , Timm Friebe , internals@lists.php.net References: <155749706.20090117211737@marcus-boerger.de> <497872B8.60807@zend.com> <4A08CA5F.7010200@zend.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2009 18:24:18.0125 (UTC) FILETIME=[DCB007D0:01C9D32E] Subject: Re: [PHP-DEV] Method call improvements From: stas@zend.com (Stanislav Malyshev) Hi! > Apologies, I'm not familiar with run-time inheritence in PHP. My > understanding was that when a classes source code is compiled, its > parent classes must be known. When is this not the case? Must it be > known for the class' first instantiation? No, the problems here are different. The process works as follows: 1. Class X source is compiled. 2. "X" is added to the class table 3. Class Y (extends X) source is compiled. 4. Since Y extends X, methods of X are added to methods of Y 5. "Y" is added to the class table Now, adding bytecode caching. Bytecode caching replaces steps 1 and 3 with "loaded from cache" - however since the identity of X can change between requests, what is stored for step 3 can not bind to X as it is now - for that there's step 4 which is executed at runtime, when the line where class is defined is executed. That means static table describing class Y can exist only after step 4, and it is not cacheable beyond the bounds of one request. However, if we now are compiling the code such as: $a->foo(); we meet with following challenges: 1. We do not know what class $a is (suppose it's X, but in most cases we won't know that) 2. If we did, we do not know what class X is (definition, as opposed to just name) at the compile time (it could be defined later) 3. If we knew what class X definition is at compile time, the above would preclude us from generating any code that binds to that definition since such code would not be cacheable. These are three independent challenges, without overcoming each of them I do not see how virtual table would be helpful. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com