Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56272 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29800 invoked from network); 11 Nov 2011 05:14:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Nov 2011 05:14:02 -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 67.192.241.163 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.163 smtp163.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.163] ([67.192.241.163:58761] helo=smtp163.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 99/97-17932-71FACBE4 for ; Fri, 11 Nov 2011 00:14:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 9257440F53; Fri, 11 Nov 2011 00:13:57 -0500 (EST) X-Virus-Scanned: OK Received: by smtp16.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 2C2C440F51; Fri, 11 Nov 2011 00:13:57 -0500 (EST) Message-ID: <4EBCAF14.4030100@sugarcrm.com> Date: Thu, 10 Nov 2011 21:13:56 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "guilhermeblanco@gmail.com" CC: PHP Internals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: SPLClassLoader RFC Thoughts And Improvements From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > This is actually already supported. > The SplClassLoader$mode does exactly that. The $mode can be one of these values: > - MODE_NORMAL: Throws error while attempting to include an unexistent file Why this should even exist? It's never OK for generic autoloader to produce any errors when it can't load the class, because it makes it unusable with other loaders. > - MODE_DEBUG: This one can work together with the other two, allowing > a validation of class/interface/trait presence in the file. Basically, > it requires the file and then checks if the item exists in scope. Not sure debug adds much here - if the class is not found, you'll be notified by the engine anyway, so what's the added value? > Actually they do not map the same file. Here is the path of each one: > new \Foo\Bar\Baz; => [path]/Foo/Bar/Baz.php > new \Foo\Bar_Baz; => [path]/Foo/Bar_Baz.php That's not what I see in the RFC: \namespace\package\Class_Name /path/to/project/lib/vendor/namespace/package/Class/Name.php > Regarding the require_once change, it's not really needed. The reason > is because class loading would never be triggered again if the > class/trait/interface is already loaded. The require_once is extremely > slow than require due to this check. The check is just a hash lookup, and you'll have to check for file existence anyway... > Based on that, I'm pro to change the class to SplPsr0ClassLoader or > SplPsr0Loader. This name looks way too L33t :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227