On 24 October 2011 15:57, David Coallier <dav...@php.net> wrote: > On 24 October 2011 16:53, Paul Dragoonis <dragoo...@gmail.com> wrote: >> On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com >> <guilhermebla...@gmail.com> wrote: >>> Hi internals, >>> >>> It's been a while since Stas accepted that, but it seems the class >>> haven't been merged since then. >>> What's the status of this? Can I expect SplClassLoader in 5.4.0? >>> >>> It seems it was approved, but wasn't merged and thread was lost in space. =( >>> >>> There's an RFC for it: https://wiki.php.net/rfc/splclassloader >>> There's a patch for it: https://github.com/metagoto/splclassloader > > If we can identify where we want it in the structure of the PHP > project, I'll be happy to merge the implementation and modify the > config files to have --enable-spl-autoloader or such.
Forgive me for not reading the code (yet) but what need is there for an --enable-spl-autoloader flag? What are peoples' thoughts on the name of the class? The word "auto" fits best with all that has come before, yet the proposal here uses "class": what about SplAutoloader? With the introduction of this new class, whatever the name, what happens to __autoload() and spl_autoload_register(), if anything? How many ways do we want/need to load a class? > > Does anyone have a preference for this? > > /ext/spl/ > /ext/spl-loader/ > /ext/spl-autoloader/ > IMO, new SPL functionality should live in ext/spl, we don't want to spread the "standard library" too far and wide. > > > -- > David Coallier > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
