Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:40499 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19840 invoked from network); 13 Sep 2008 02:08:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Sep 2008 02:08:42 -0000 Authentication-Results: pb1.pair.com smtp.mail=greg@chiaraquartet.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=greg@chiaraquartet.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error) X-PHP-List-Original-Sender: greg@chiaraquartet.net X-Host-Fingerprint: 208.83.222.18 unknown Linux 2.6 Received: from [208.83.222.18] ([208.83.222.18:49924] helo=mail.bluga.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 95/23-00143-7A02BC84 for ; Fri, 12 Sep 2008 22:08:41 -0400 Received: from mail.bluga.net (localhost.localdomain [127.0.0.1]) by mail.bluga.net (Postfix) with ESMTP id A0D85C1011C; Fri, 12 Sep 2008 19:07:49 -0700 (MST) Received: from [192.168.0.106] (CPE-76-84-4-101.neb.res.rr.com [76.84.4.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bluga.net (Postfix) with ESMTP id 37E74C1011B; Fri, 12 Sep 2008 19:07:49 -0700 (MST) Message-ID: <48CB20BA.4070609@chiaraquartet.net> Date: Fri, 12 Sep 2008 21:08:58 -0500 User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Stanislav Malyshev CC: internals@lists.php.net References: <48C59D5C.4050507@chiaraquartet.net> <48C5A909.4030502@zend.com> <48C602D5.6020704@chiaraquartet.net> <48C6A6AA.7050003@zend.com> <48C9F2F6.4080007@chiaraquartet.net> <48CAC1EF.2090501@zend.com> In-Reply-To: <48CAC1EF.2090501@zend.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorderissues) From: greg@chiaraquartet.net (Gregory Beaver) Stanislav Malyshev wrote: > Hi! > >> The caching is at runtime. Basically, it's in executor_globals, and so >> is not linked to any opcode array (I couldn't figure out any other >> globally accessible storage location). It works like an associative >> array. If file X.php loads XMLReader in namespace namespacename, it >> creates this entry: >> >> array( >> 'X.php\0namespacename::XMLReader' => {class entry for XMLReader} >> ); > > I though a bit about that patch, and I see following problems with it: > > 1. If you do not use autoloading, you still can get different > resolution, e.g.: > > namespace foo; > $a = new XMLReader; > > resolves to ::XMLReader and cached for this file. But suppose some other > file, somewhere, loaded foo::XMLReader prior to that. Then the same code > here would resolve now to foo::XMLReader as before, right? > Isn't it the same scenario you complained about? If so this patch does > not solve this for 100% of cases, unless I misunderstand how the patch > works. > > 2. While the caching indeed helps per-file, typical OO application > contains dozens of files, and each file may use dozens of internal > classes (my install has 100+ internal classes). Meaning, there is still > potential for hundreds of non-cacheable exhaustive autoload searches. > This is not a good scenario. Your first point is correct, and the second is interesting, but does not quite match reality. I whipped up a script to count the number of internal vs. user classes in a project, it's at http://pear.php.net/~greg/detect_classes.phps I ran it on PEAR2, which is a pre-namespace project at the moment, and came up with these stats: Internal classes: 239 User classes: 768 in 171 files I ran the same script over PEAR, and got: Internal classes: 110 User classes: 2027 in 231 files Now, you may argue that these are atypical OO applications, so I also ran the script over Zend Framework 1.5, with these results: Internal classes: 950 User classes: 16167 in 1821 files In other words, there is simply no comparison. Userspace class usage outnumbers internal class usage by an order of magnitude in typical OO PHP code. PEAR2 uses an average of 2 internal classes per file, and 7 userspace classes. PEAR uses an average of 0.5 internal classes per file, and 8 userspace classes per file. Zend Framework uses an average of 0.5 internal classes per file and ~9 userspace classes per file. Thus, if I had to choose between defaulting to current namespace (as you suggested) and to internal classes, the choice is easy. I would choose current namespace because there would be far fewer use statements, and the behavior is deterministic. The script is at: http://pear.php.net/~greg/detect_classes.phps run with "php detect_classes.php /path/to/files" Oh, and the script is one of the few cases where there are 3 internal classes used and only 1 userspace class :). Thanks, Greg