Re: SplClassLoader

On Nov 4, 2011, at 7:19 AM, Anthony Ferrara wrote: > 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. Exactly. spl_autoload_register provides the ability for autoloading to work among systems. What it does *not* do is define the layout of files/file systems or what should happen upon a file not found. As Jonathan noted, this is a documentation problem. Implementing a new bit of functionality for the purpose of offering a standard is wrong IMHO. The other problem is this would only *offer* a standard. > > @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.. This still feels like a docs issue. spl_autoload_register provides everything you need to create your own autoloader. This suggestion would just add more overhead if implemented in core (if that is your intent). Will > > @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 <jbondc@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() >> >> >>