Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56186 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90406 invoked from network); 9 Nov 2011 10:24:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Nov 2011 10:24:07 -0000 Authentication-Results: pb1.pair.com header.from=christian.kaps@mohiva.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=christian.kaps@mohiva.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mohiva.com from 80.67.18.44 cause and error) X-PHP-List-Original-Sender: christian.kaps@mohiva.com X-Host-Fingerprint: 80.67.18.44 smtprelay02.ispgateway.de Linux 2.6 Received: from [80.67.18.44] ([80.67.18.44:33901] helo=smtprelay02.ispgateway.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 48/10-24322-5C45ABE4 for ; Wed, 09 Nov 2011 05:24:06 -0500 Received: from [80.67.16.117] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1RO5K6-0002QC-OX for internals@lists.php.net; Wed, 09 Nov 2011 11:24:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 09 Nov 2011 11:24:02 +0100 To: In-Reply-To: References: <4EB81703.7030605@hoa-project.net> <4EB81C84.8010609@hoa-project.net> <4EB820BB.2030009@lsces.co.uk> <4EB822D4.4060306@hoa-project.net> <4EB89C36.5000503@garfieldtech.com> <4EB8A22B.8000607@lerdorf.com> Message-ID: X-Sender: christian.kaps@mohiva.com User-Agent: Roundcube Webmail/0.6 X-Df-Sender: Y2hyaXN0aWFuLmthcHNAbW9oaXZhLmNvbQ== Subject: Re: [PHP-DEV] SplClassLoader RFC Voting phase From: christian.kaps@mohiva.com (Christian Kaps) Hi, I'm fine with the most of the implementation. But I have some suggestions to optimize it. 1. The interface should be named SplClassLoader and the register and unregister methods should be removed. It should be possible to define class loader implementations without registering them as autoloader because autoloading isn't the only way to load classes. A class loader could as example return the ReflectionClass instance for the loaded class. I think the current interface is to restrictive in this case. As compromise it would be possible to define a SplClassAutoloader interface too. This interface extends the SplClassLoader interface and defines the methods register and unregister. interface SplClassAutoloader extends SplClassLoader { public function register($prepend = false); public function unregister(); } As a side note, the two interfaces doesn't violate the Single responsibility principle. I know the reference implementation is named as SplClassLoader but this should be renamed into SplDefaultAutoloader or SplPsrAutoloader if implements the SplClassAutoloader or as SplPsrClassloader or SplDefaultClassloader if implements the SplClassLoader interface. 2. The function spl_autoload_register() should accept all SplClassLoader implementations. I know it's already possible with the following syntax: $classLoader = new MyCustomClassLoader(); spl_autoload_register(array($classLoader, 'load')); But the following syntax seems more consistent to me: $classLoader = new MyCustomClassLoader(); spl_autoload_register($classLoader); Christian Am 09.11.2011 02:23, schrieb guilhermeblanco@gmail.com: > For all those interested, I implemented what I referred as item 2: > > > After some thought it makes sense, but only if interface then defines > the setMode prototype. > The background for this is supported if the user decides to enhance > the base class to support caching, requiring the injection of the > Cache layer in constructor. If it's part of the interface, it cannot > be changed. > > > RFC is now updated covering this. If you have more questions or > suggestions, feel free to tell me. > > On Tue, Nov 8, 2011 at 3:55 PM, guilhermeblanco@gmail.com > wrote: >> Hi Nikita, >> >> Thanks. >> It's your option and I won't fight. But it seems my proposal is not >> yet 100%. >> Some things I have either identified or people have reported. >> >> 1- Remove ->register() and ->unregister(), and make the >> spl_autoload_register to support SplClassLoader. >> >> I'm really +0 on this one. >> But since the proposal covers an OO approach for autoload, it makes >> sense the registering is pat of the available API, not in procedural >> land. >> >> 2- Remove constructor prototype in interface >> >> After some thought it makes sense, but only if interface then >> defines >> the setMode prototype. >> The background for this is supported if the user decides to enhance >> the base class to support caching, requiring the injection of the >> Cache layer in constructor. If it's part of the interface, it cannot >> be changed. >> I took this example after looking at Symfony's >> ApcUniversalClassLoader: >> >> https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.php >> >> >> What do you think about these 2 points? >> >> Even if you're against the proposal, for sure you can still help to >> make it consistent. >> >> >> Cheers, >> >> On Tue, Nov 8, 2011 at 3:39 PM, Nikita Popov >> wrote: >>> On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com >>> wrote: >>>> Because there's no need to bring to C a single foreach. >>>> Also, if you re-read the RFC, you'll see that SplClassLoader is >>>> extendable for personalized developer needs, such as an addAll or >>>> an >>>> APC lookup. >>> After your changes the RFC looks much more decent. I am still >>> opposed >>> to the idea of this going into core (mainly because there is no >>> necessity), but now the implementation is somewhat more useful. >>> >>> Nikita >>> >> >> >> >> -- >> Guilherme Blanco >> Mobile: +55 (11) 8118-4422 >> MSN: guilhermeblanco@hotmail.com >> São Paulo - SP/Brazil >> > > > > -- > Guilherme Blanco > Mobile: +55 (11) 8118-4422 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil