I've been following this but not on the internal portions of PSR-0... Why it is needed: Currently all of the implementations on the autoloading side is pushed in through a custom class or function inside of spl_autoload whereas the registered autoloading takes place. Currently each framework that utilizes this implements it within their own source code: * ZF: http://framework.zend.com/apidoc/1.11/db_Loader_Autoloader.html#%5CZend_Loader_Autoloader * Symfony: https://github.com/symfony/ClassLoader
By standardizing this inside of an extension gains us 2 very major features (IMO): 1. Extension would force the standard but could be extended to add in various needs in the event there is additional functionality. 2. Easier for someone to implement PSR-0 without having to create a custom autoloader elsewhere The speed of this should give us a slight bump (only slight seeing as w/o the use of absolute paths apc doesn't really gain us anything). Overall; it should clean up the various implementations that are scattered about. Additionally; this should gain greater acceptance and an easier implementations by people creating their custom frameworks or leveraging something such as PSR-0. >From the RFC prospective it does seem like many things are missing: 1. Examples * The easiest example being that of a folder structure and class naming such as in PSR-0 with the instance of the autoloader. 2. Use Cases * Examples of framework cases... additionally extending framework libraries in separate folders. Regards, Mike On Mon, Oct 24, 2011 at 11:25 AM, Pierre Joye <pierre....@gmail.com> wrote: > hi, > > I'd to be in favor to include it. However I would like to hear more > from the people behind PSR-0 to be sure that it is actually what is > needed and to complete the RFC (it is rather missing real info, > examples and tests). > > Please also update the patch and attach it to the RFC. > > Cheers, > > On Mon, Oct 24, 2011 at 4: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 > > > > I'm not 100% sure the patch still works since it's been over 1 year > > since it was proposed... =\ > > > > Cheers, > > > > On Fri, Jul 15, 2011 at 4:07 PM, Stas Malyshev <smalys...@sugarcrm.com> > wrote: > >> Hi! > >> > >> On 6/29/11 6:31 AM, Mike Willbanks wrote: > >>>> > >>>> There's a RFC covering this. There's a patch also. > >>>> > >>>> https://wiki.php.net/rfc/splclassloader > >>> > >>> > >>> This one seems to have fallen through the cracks? > >> > >> Well, nobody proposed it in time (especially not the RFC author :) > >> > >>> * The other implementation I could see is to modify spl_autoload to be > >>> able > >>> to pass it a parameter for the auto loading type - right now it will > >>> attempt > >>> to autoload everything lowercase (been brought up a few times). > >> > >> I think the class looks better. I think RFC needs to be expanded with > >> description of what the class actually does and how, and then if there > are > >> no objections I think we could take it into 5.4.0, since the > implementation > >> already exists. > >> -- > >> Stanislav Malyshev, Software Architect > >> SugarCRM: http://www.sugarcrm.com/ > >> (408)454-6900 ext. 227 > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > > > > > -- > > 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 > > > > > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >
