Re: SplClassLoader RFC Voting phase

On Tue, Nov 8, 2011 at 6:55 PM, guilhermeblanco@gmail.com < 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. > +1 on remove, don't duplicate things already part of php. While on duplication, why complicate things by having custom $includePathLookup support? This is already handled by php isn't it? > > 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 > > +1 on removing constructor from interface. But imo SplClassLoader should have a constructor where you can optionally provide a hash of namespace and path, so you can do: spl_autoload_register( new SplClassLoader( array( 'ns' => 'path/', 'ns2' => 'path2/' ) ) ); (assuming spl_autoload_register gets native support for SplAutoloader, otherwise it it will of course have to be provided as a callback)