Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38915 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 42801 invoked from network); 11 Jul 2008 21:18:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jul 2008 21:18:02 -0000 Authentication-Results: pb1.pair.com header.from=greg@chiaraquartet.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=greg@chiaraquartet.net; spf=permerror; 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:50515] helo=mail.bluga.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 39/C3-18817-80EC7784 for ; Fri, 11 Jul 2008 17:18:01 -0400 Received: from mail.bluga.net (localhost.localdomain [127.0.0.1]) by mail.bluga.net (Postfix) with ESMTP id 1F41A98DC40; Fri, 11 Jul 2008 14:17:47 -0700 (MST) Received: from [192.168.1.124] (static-64-115-191-41.isp.broadviewnet.net [64.115.191.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bluga.net (Postfix) with ESMTP id 61DD298DC38; Fri, 11 Jul 2008 14:17:46 -0700 (MST) Message-ID: <4877CE04.4070104@chiaraquartet.net> Date: Fri, 11 Jul 2008 17:17:56 -0400 User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Stanislav Malyshev CC: Lukas Kahwe Smith , PHP Developers Mailing List , Dmitry Stogov References: <486FA5FB.1000300@php.net> <4872B5D4.1000205@zend.com> In-Reply-To: <4872B5D4.1000205@zend.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: towards a 5.3 release From: greg@chiaraquartet.net (Greg Beaver) Stanislav Malyshev wrote: > Hi! > >> This fixes the logic problem, and re-introduces the performance >> slowdown for internal classes. FORTUNATELY there is a simple >> solution to this, which is to "use" all global classes: > > The thing is since it'd work without "use", most users would do it > that way and have horrible code. But if you can do use ::Exception, > you can the same way do use Foo::Exception, right? So what's the > difference? The difference is in what you quoted - name resolution is non-deterministic with current implementation. The suggested change always works the same way. It turns out my internet access is even worse than I thought, so I may only be reading/replying once every week to two weeks until August, please bear with me :/ In other words, with the current implementation, you can just do "use Foo::Exception;" and it works, but if you *forget* to do the use statement, you can get unpredictable behavior with no warning until your code starts not working properly. With the suggested change of name resolution, your code always works as you designed it, but if you forget to "use ::Exception", then your code is simply slightly slower (1 extra call to autoload if it exists), but still works properly. It also tilts the "use" towards internal classnames, which in my experience tend to be outnumbered by userspace classnames, so it will reduce code size, making it more readable. Greg