SplClassLoader

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

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()