# SplClassLoader - Thread: https://externals.io/message/53595 - Original archive: https://news-web.php.net/php.internals/53595 - Started by rod@pu-gh.com on 2011-06-27T10:19:23+00:00 - Messages: 41 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/53595.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53595 — rod@pu-gh.com — 2011-06-27T10:19:23+00:00 URL: https://externals.io/message/53595#53595 Quick question: is there any planned inclusion in PHP for an SplClassLoader? Cheers - rod. --- ## #53596 — Hannes Magnusson — 2011-06-27T10:47:59+00:00 URL: https://externals.io/message/53595#53596 · In reply to: #53595 > Quick question: is there any planned inclusion in PHP for an SplClassLoader? > What would that class do that the spl_autoload*() functions don't? -Hannes --- ## #53597 — Dennis Haarbrink — 2011-06-27T10:57:51+00:00 URL: https://externals.io/message/53595#53597 · In reply to: #53596 I suppose what he means is a classloader *implementation*. Something along the lines of: function($class) { return str_replace('\\', DIRECTORY_SEPARATOR, $class) . '.php'; } 2011/6/27 Hannes Magnusson > > > […] > SplClassLoader? > > […] > > What would that class do that the spl_autoload*() functions don't? > > -Hannes --- ## #53598 — rod@pu-gh.com — 2011-06-27T10:59:41+00:00 URL: https://externals.io/message/53595#53598 · In reply to: #53597 Yes sorry this is what I mean, a PSR0 compliant autoloader class built in as standard. $loader = new SplClassLoader(); $loader->register( '/path/to/my/library' ); etc... > I suppose what he means is a classloader *implementation*. > Something along the lines of: > function($class) { >     return str_replace('\\', DIRECTORY_SEPARATOR, $class) . '.php'; > } > > 2011/6/27 Hannes Magnusson > > […] --- ## #53601 — guilhermeblanco@gmail.com — 2011-06-27T14:02:13+00:00 URL: https://externals.io/message/53595#53601 · In reply to: #53598 Hannes, There's a RFC covering this. There's a patch also. https://wiki.php.net/rfc/splclassloader []s, > Yes sorry this is what I mean, a PSR0 compliant autoloader class built > in as standard. > > $loader = new SplClassLoader(); > $loader->register( '/path/to/my/library' ); > etc... > > > > > […] > > -- > > > > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #53654 — Mike Willbanks — 2011-06-29T13:31:38+00:00 URL: https://externals.io/message/53595#53654 · In reply to: #53601 > > 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? I know this would benefit many of the frameworks that are out there and give a speed bump to people utilizing them. Is this a possibility for 5.4? * 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). Regards, Mike --- ## #53974 — Stas Malyshev — 2011-07-15T19:07:19+00:00 URL: https://externals.io/message/53595#53974 · In reply to: #53654 Hi! > > […] > > > 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 --- ## #55921 — guilhermeblanco@gmail.com — 2011-10-24T14:47:29+00:00 URL: https://externals.io/message/53595#55921 · In reply to: #53974 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, > Hi! > > > > […] > > Well, nobody proposed it in time (especially not the RFC author :) > > > […] > > 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 > > -- > > > > -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #55922 — Paul Dragoonis — 2011-10-24T14:53:22+00:00 URL: https://externals.io/message/53595#55922 · In reply to: #55921 On Mon, Oct 24, 2011 at 3:47 PM, guilhermeblanco@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... =\ I was also looking for this yesterday while implementing namespaces into my project to be PSR-0 complaint. I did see metagoto's implementation however would prefer to see something in /ext/* Lets push it ! all major php libs would significantly benefit from this addition from user-land into core. - Paul Dragoonis. > > Cheers, > > > > […] > > > > -- > Guilherme Blanco > Mobile: +55 (11) 8118-4422 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil --- ## #55923 — David Coallier — 2011-10-24T14:57:22+00:00 URL: https://externals.io/message/53595#55923 · In reply to: #55922 > On Mon, Oct 24, 2011 at 3:47 PM, guilhermeblanco@gmail.com > wrote: > > […] 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. Does anyone have a preference for this? /ext/spl/ /ext/spl-loader/ /ext/spl-autoloader/ -- David Coallier --- ## #55924 — Paul Dragoonis — 2011-10-24T14:59:39+00:00 URL: https://externals.io/message/53595#55924 · In reply to: #55923 > > > […] > > 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. > > Does anyone have a preference for this? > >    /ext/spl/ >    /ext/spl-loader/ >    /ext/spl-autoloader/ > Hey David, Since it has the prefix 'Spl' then I think it makes sense to add it as a class to the existing /ext/spl/ extension, having it as its own extension would be overkill me thinks. - Paul Dragoonis. > > > -- > David Coallier --- ## #55925 — Peter Cowburn — 2011-10-24T15:20:41+00:00 URL: https://externals.io/message/53595#55925 · In reply to: #55923 > > > […] > > 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 --- ## #55926 — Pierre Joye — 2011-10-24T16:25:12+00:00 URL: https://externals.io/message/53595#55926 · In reply to: #55921 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, guilhermeblanco@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, > > > > […] > > > > -- > Guilherme Blanco > Mobile: +55 (11) 8118-4422 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55927 — Mike Willbanks — 2011-10-24T16:45:12+00:00 URL: https://externals.io/message/53595#55927 · In reply to: #55926 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 > 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, guilhermeblanco@gmail.com > wrote: > > […] > =( > > […] > wrote: > > […] > are > > […] > implementation > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55928 — Stas Malyshev — 2011-10-24T16:51:38+00:00 URL: https://externals.io/message/53595#55928 · In reply to: #55927 Hi! > By standardizing this inside of an extension gains us 2 very major features > (IMO): But we already have the extension, don't we? > 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. Yes, the RFC is not really up-to-date or complete. Another thing is I wouldn't really want to add anything that isn't a bugfix or BC fix or anything of this nature after RC1 is out. So if there's support for getting it into SPL, proper RFC, consensus gathering, patch, and all the process should be complete by Nov. 10, otherwise it's not in for 5.4.0. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #55929 — Mike Willbanks — 2011-10-24T16:52:44+00:00 URL: https://externals.io/message/53595#55929 · In reply to: #55925 On Mon, Oct 24, 2011 at 10:20 AM, Peter Cowburn wrote: > > > […] > space. =( > > […] > > Forgive me for not reading the code (yet) but what need is there for > an --enable-spl-autoloader flag? > I agree; I do not believe that there is a need for an enable flag in this case. It should just be there or not at all. > > 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? I believe by calling a class SplAutoloader when there is already an implementation of spl_autoload that does something very different it would be advised to not name it of the same sort... this is what people would start to think about. The name SplClassLoader is much more specific. If we needed to keep the word "Auto" it would seem better named SplClassAutoLoader. spl_autoload is completely separate from __autoload today. Also __autoload does differ from the spl_autoload facility in several ways and is not recommended even from the manual standpoint: www.php.net/autoload. Secondarily; a class loader cannot autoload functions - it is made to only implement PSR-0 and nothing more. While you may use spl_autoload to load classes the implementation can also load in functions. This class is really just enforcing a specific standardization. --- ## #55930 — David Coallier — 2011-10-24T16:56:00+00:00 URL: https://externals.io/message/53595#55930 · In reply to: #55929 > > > […] > > > I believe by calling a class SplAutoloader when there is already an > implementation of spl_autoload that does something very different it would > be advised to not name it of the same sort... this is what people would > start to think about.  The name SplClassLoader is much more specific.  If we > needed to keep the word "Auto" it would seem better named > SplClassAutoLoader. > > spl_autoload is completely separate from __autoload today.  Also __autoload > does differ from the spl_autoload facility in several ways and is not > recommended even from the manual standpoint: www.php.net/autoload. >  Secondarily; a class loader cannot autoload functions - it is made to only > implement PSR-0 and nothing more.  While you may use spl_autoload to load > classes the implementation can also load in functions.  This class is really > just enforcing a specific standardization. > I've started toying around with adjusting the patch. A bit of rewrite is required but I'm attempting to modify the patch to be included directly in SPL with the name SplClassLoader so that one can do: $cl = new \SplClassLoader(..., ...); Once the patch is adjusted to fit with SPL, we can revisit the name however it is going to be used. -- David Coallier --- ## #55939 — David Coallier — 2011-10-24T21:25:14+00:00 URL: https://externals.io/message/53595#55939 · In reply to: #55930 > > I've started toying around with adjusting the patch. A bit of rewrite > is required but I'm attempting to modify the patch to be included > directly in SPL with the name SplClassLoader so that one can do: > >    $cl = new \SplClassLoader(..., ...); > > Once the patch is adjusted to fit with SPL, we can revisit the name > however it is going to be used. For the record: https://gist.github.com/1310352 (I know there are Whitespaces issues, I'll get those resolved) I'll be adding the tests tomorrow morning and then making sure the RFC is adjusted. -- David Coallier --- ## #55940 — Pierre Joye — 2011-10-24T21:49:25+00:00 URL: https://externals.io/message/53595#55940 · In reply to: #55939 hi, Could you open a FR at bugs.php.net and attach the patch to it please? Could be easier to track (and the # to the RFC too :) > > […] > > For the record: https://gist.github.com/1310352 (I know there are > Whitespaces issues, I'll get those resolved) > > I'll be adding the tests tomorrow morning and then making sure the RFC > is adjusted. > > -- > David Coallier > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55941 — David Coallier — 2011-10-24T21:55:07+00:00 URL: https://externals.io/message/53595#55941 · In reply to: #55940 > > Could you open a FR at bugs.php.net and attach the patch to it please? > Could be easier to track  (and the # to the RFC too :) > Yeah I'll do that once I have the tests adjusted and once I know the patch actually works as expected. -- David Coallier --- ## #55946 — guilhermeblanco@gmail.com — 2011-10-25T02:39:47+00:00 URL: https://externals.io/message/53595#55946 · In reply to: #55941 Hi internals, For all those interested, I have updated the RFC with better explanation, included example implementation and also example usage. If you have any other wishes, doubts, etc, feel free to ask on this thread and I'll quickly answer here and also update the RFC accordingly. The url for the RFC is: https://wiki.php.net/rfc/splclassloader Cheers, > > […] > > Yeah I'll do that once I have the tests adjusted and once I know the > patch actually works as expected. > > -- > David Coallier > > -- > > > > -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #55957 — Benjamin Eberlei — 2011-10-25T10:49:24+00:00 URL: https://externals.io/message/53595#55957 · In reply to: #55946 I think the following two requirements should be covered by configuration aswell: 1. Have the autoloader be silent, i.e. doing a `file_exists()` check. API idea $loader = new SplClassLoader(..., SplClassLoader::SILENT); 2. Have a ASSERT_CLASS_EXISTS mode, i.e. after the require an "if(!class_exists($class))" => throw new LogicException("SplClassLoader expects class $class to be in $file, but after requiring the file this class is still not loaded."); API here aswell "new SplCloassLoader(..., SplClassLoader::ASSERT_CLASS_EXISTS)" greetings, Benjamin On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > Hi internals, > > For all those interested, I have updated the RFC with better > explanation, included example implementation and also example usage. > If you have any other wishes, doubts, etc, feel free to ask on this > thread and I'll quickly answer here and also update the RFC > accordingly. > > The url for the RFC is: https://wiki.php.net/rfc/splclassloader > > Cheers, > > > > […] > > > > -- > Guilherme Blanco > Mobile: +55 (11) 8118-4422 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil --- ## #55962 — ar@ez.no — 2011-10-26T11:30:19+00:00 URL: https://externals.io/message/53595#55962 · In reply to: #55946 On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > Hi internals, > > For all those interested, I have updated the RFC with better > explanation, included example implementation and also example usage. > If you have any other wishes, doubts, etc, feel free to ask on this > thread and I'll quickly answer here and also update the RFC > accordingly. > As sent to the PHP-SWG list, a small change / addition to PSR-0 would simplify the matching considerably. If this rule: * Each “_” character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The “_” character has no special meaning in the namespace. is changed to * Each “_” character in the CLASS NAME and NAMESPACE is converted to a DIRECTORY_SEPARATOR. Or a strict mode is added to enable that, then you'll reduce 6 string function to 2, and still have backward support for PEAR class naming(w/o namespace). > The url for the RFC is: https://wiki.php.net/rfc/splclassloader > > Cheers, > > > > […] > > > > -- > Guilherme Blanco > Mobile: +55 (11) 8118-4422 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil --- ## #55963 — ar@ez.no — 2011-10-26T11:38:20+00:00 URL: https://externals.io/message/53595#55963 · In reply to: #55957 On Tue, Oct 25, 2011 at 12:49 PM, Benjamin Eberlei wrote: > I think the following two requirements should be covered by configuration > aswell: > > 1. Have the autoloader be silent, i.e. doing a `file_exists()` check. API > idea > $loader = new SplClassLoader(..., SplClassLoader::SILENT); > 2. Have a ASSERT_CLASS_EXISTS mode, i.e. after the require an > "if(!class_exists($class))" => throw new LogicException("SplClassLoader > expects class $class to be in $file, but after requiring the file this > class > is still not loaded."); API here aswell "new SplCloassLoader(..., > SplClassLoader::ASSERT_CLASS_EXISTS)" > What if 5.4 enhanced `class_exists()` to send a second true argument (an optional argument, where default should be false) to autoloaders, then users wouldn't have to deal with silent vs noisy modes at all. So signature of autoload functions becomes: function load( string $className, bool $checkExistence = false ); In the case of splClassLoader, $checkExistence = false would for instance mean you would get a *E_COMPILE_ERROR *(requrie) if the class does not exist but does match the configured root name spaced to be handled, if the argument is true, then a bool is returned. > > greetings, > Benjamin > > On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com < > guilhermeblanco@gmail.com> wrote: > > > […] > please? > > […] --- ## #55967 — Matthew Weier O'Phinney — 2011-10-26T18:37:11+00:00 URL: https://externals.io/message/53595#55967 · In reply to: #55962 > --bcaec5216025460b0e04b031fc2a > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com < > guilhermeblanco@gmail.com> wrote: > > > […] > > > As sent to the PHP-SWG list, a small change / addition to PSR-0 would > simplify the matching considerably. > > If this rule: > * Each "_" character in the CLASS NAME is converted to a > DIRECTORY_SEPARATOR. The "_" character has no special meaning in > the namespace. > > is changed to > * Each "_" character in the CLASS NAME and NAMESPACE is converted to a > DIRECTORY_SEPARATOR. > > Or a strict mode is added to enable that, then you'll reduce 6 string > function to 2, and still have backward support for PEAR class naming(w/o > namespace). Actually, it still works, with no modifications. PEAR 1 classes exist in the global namespace, and as such, the "_" in the classname rule triggers. As such, a PSR-0 compatible autoloader will load PEAR 1 classes as well as those written using namespaces in PHP 5.3. The difference right now is that PSR-0 now differentiates namespace conventions from class name conventions. My main point, however, is that the standard was ratified quite some time ago already -- we just now have parties interested in creating a C-level implementation compatible with the standard to (a) make usage simpler, and (b) better optimize performance. We should not be debating the standard here, just the implementation. > > […] > > --bcaec5216025460b0e04b031fc2a-- -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc --- Next page: https://externals.io/message/53595.md?page=2