Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33929 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21808 invoked by uid 1010); 11 Dec 2007 20:22:19 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 21793 invoked from network); 11 Dec 2007 20:22:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Dec 2007 20:22:19 -0000 Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 212.25.124.162 mail.zend.com Windows 2000 SP4, XP SP1 Received: from [212.25.124.162] ([212.25.124.162:36344] helo=mx1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D3/54-17330-A71FE574 for ; Tue, 11 Dec 2007 15:22:19 -0500 Received: from us-ex1.zend.com ([192.168.16.5]) by mx1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 22:22:16 +0200 Received: from [192.168.16.91] ([192.168.16.91]) by us-ex1.zend.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 12:22:13 -0800 Message-ID: <475EF175.2030304@zend.com> Date: Tue, 11 Dec 2007 12:22:13 -0800 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?David_Z=FClke?= CC: Matthias Pigulla , Sam Barrow , internals@lists.php.net References: <11970653983080000@9866357972520000.9866341568840000> <475BDDF1.7040605@ctindustries.net> <1723341090.20071210220025@marcus-boerger.de> <1197323296.3922.5.camel@sbarrow-desktop> <00A2E2156BEE8446A81C8881AE117F199A0715@companyweb> <475ED038.3080004@zend.com> <7F9E1E02-FF89-474B-9E94-007747B3637A@bitxtender.com> In-Reply-To: <7F9E1E02-FF89-474B-9E94-007747B3637A@bitxtender.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 20:22:13.0357 (UTC) FILETIME=[83E041D0:01C83C33] Subject: Re: AW: [PHP-DEV] Namespace resolution From: stas@zend.com (Stanislav Malyshev) > Ah. Yes, that makes perfect sense to me. The logical solution must be > then, however, not to implement namespaces at all, or requiring code It's not a solution, it's refusing to solve a problem. > for the behavior from an implementational standpoint, but I think it > really is obvious that such a namespace solution would be completely > useless, as it would not be possible under any circumstances to provide If it's "obvious" for you that namespaces are useless, probably you need to give your obviousness-meter a check-up. They were found useful by many people, even if there are things to work out here and there - which happens with each new concept not tested in the field. > Or, as an alternative, introduce an optional third argument to > spl_autoload_register where people can give a namespace name for which > the autoloading should be performed. That would cut down overhead since There's no such thing as "namespace name for which autoloding is performed". Autoloader receives a full class name, that's it. How this name was created is irrelevant. > just the autoload functions of currently imported namespaces would have > to be called. I don't understand what do you mean here, but it doesn't matter, since autoload call on each class access is very bad regardless of how it's implemented internally. > I don't really think, though, that doing something like use __php__; is > a tall order, is it? It would only be necessary for those that consume "use whatever;" is a no-op. There's even warning about it in the engine. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com