Jonathan, > The problem with spl_autoload_register() is it isn't clear what the > autoloading function is supposed to do if the class if not found.
Then that's a documentation problem. If you throw an exception in yours, sure that's going to cause problems for anyone else. It's 100% possible (and easy) to play nice. But that brings up another problem with PSR-0. It's possible to use 100% valid PHP and have it throw a fatal error. Let's assume a file exists named foo/bar.php new foo\bar; new foo_bar; That will fatal error 100% of the time (as long as both of those classes aren't in that file), since they both map to the same file, *and* PSR-0 mandates require instead of require_once. So even if I declare an autoloader later to load my foo_bar class, it won't work because it'll never get there. Additionally, since it's not checking the existance of the file, it's impossible for me to add a class to an existing namespace from outside of its root. Say we have /lib/foo/bar/baz.php. If I wanted to add a class \foo\bar\bat.php, I'd **have** to add it to that directory, other wise I'd get a fatal error. It's not a far cry. That's basically what Kohana does right now with their autoloader... So that's two more inconsistencies with what's 100% valid PHP but could cause fatal errors with PSR-0. @Ferenec >I think that the best solution would be having a generic autoloader >infrastructure in the core, and having separate autoloading >strategies(http://en.wikipedia.org/wiki/Strategy_pattern) offered, and one of >them could be PSR-0(we could also add the PEAR/PEAR2 autoloader, etc.). That's something that I could get behind.. @Andre >It will be a more modern alternative to >http://www.php.net/manual/en/function.spl-autoload.php And I don't feel that function belongs in the core at all either. It's there, so whatever, but at least that's consistent with how PHP behaves... > So yes, there is already something like this in core, so I really don't get > why you are so against this, not seeing the wood for the trees? :) Well, nothing like this exists in core. First, PSR-0 doesn't degrade gracefully. If it can't map, it fatal errors. Nothing else does so in the core in an area where it's 100% possible to recover anyway. Secondly, nothing in the core requires you to adhere to a code-level convention for it to work. I'm sure there are more arguments against that, but eih. Not seeing the forest for the trees? On the opposite. I see what this will open up if included. Why can't my autoloader be put in the core when PSR-0 is in it? Based on what you said, it's 100% optional, so why not? Should Runkit be put in core? Sure, it's optional to use, so why not? Heck, while we're at it, all of PECL should be moved in core. Who cares how stable or nice they interact with the core. After all, the core of the language is not like it's widely used by others. The language should care about *possibility* not picking a side when it's trivial to implement in PHP land. You're talking about saving 8 or 10 lines of PHP code... So I would argue that it's more not seeing the forest because you're looking too close at one tree... Anthony On Fri, Nov 4, 2011 at 6:43 AM, Jonathan Bond-Caron <jbo...@openmv.com> wrote: > On Thu Nov 3 03:06 PM, Will Fitch wrote: >> Wouldn't you consider spl_autoload_register an interoperability >> solution? Only your defined autoloading function would then need to >> know how your file system is structured, there'd be no need for >> include_path declarations and you wouldn't have to explicitly declare >> paths for each class. >> > > The problem with spl_autoload_register() is it isn't clear what the > autoloading function is supposed to do if the class if not found. > So no I don't think spl_autoload_register() solves an interoperability > problem. SplClassLoader somewhat does a better job by forcing a common > implementation... > > function FrameworkA_autoload($class) { > if( !isset($AmapToFile[$class]) ) > throw new Exception('Class '. $class . ' not found!'); > > include_once($AmapToFile[$class]); > } > function FrameworkB_autoload($class) { > require_once($BmapToFile[$class]); > } > function FrameworkC_autoload($class) { > include_once($CmapToFile[$class]); > } > > spl_autoload_register('FrameworkA_autoload'); > spl_autoload_register('FrameworkB_autoload'); > spl_autoload_register('FrameworkC_autoload'); > > So both 'FrameworkB_autoload', 'FrameworkC_autoload' are never called. > > Btw, I would hope that any 'standard' would actually that try to talk about > other autoloaders and how they should behave. > > https://gist.github.com/221634 > > See comments about include() or require() > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
