PS: I'd love to point you all this article... this is something that motivates me to push this RFC forward. =)
http://phpmaster.com/the-importance-of-standards/ Cheers, On Tue, Nov 8, 2011 at 11:23 PM, guilhermebla...@gmail.com <guilhermebla...@gmail.com> wrote: > For all those interested, I implemented what I referred as item 2: > > <quote> > 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. > </quote> > > 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, guilhermebla...@gmail.com > <guilhermebla...@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 <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 >> > > > > -- > Guilherme Blanco > Mobile: +55 (11) 8118-4422 > MSN: guilhermebla...@hotmail.com > São Paulo - SP/Brazil > -- 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