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 <nikita....@googlemail.com> wrote: > On Tue, Nov 8, 2011 at 6:28 PM, guilhermebla...@gmail.com > <guilhermebla...@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: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
