From: stanlemon at mac dot com
Operating system: Mac OS X 10.4.10
PHP version: 5.2.4
PHP Bug Type: SPL related
Bug description: spl_autoload_register() stack order
Description:
------------
spl_autoload_register() builds the autoload stack based upon the
sequence in which methods are added to the stack. This gives precedence
to the first methods loaded into the stack, not the subsequent ones.
This can be an issue when someone creates an initial autoloader to cover
the most generic of situations and is designed to error out when nothing
can be found, either by using require() or by throwing an exception. If
I wanted to add a secondary autoloader to account for an additional set
of classes I would need to either unregister the initial autoloader and
account for those scenarios or change the order of the autoload stack.
I realize this suggest an API change, which is obviously less than
desirable. Perhaps, though, a method like spl_autoload_preregister()
could be added to prepend autoloaders to the stack, rather than append,
thus giving them precedence in the call order.
Reproduce code:
---------------
function genericAutoload($class) {
if (!include($class . '.php')) {
throw new Exception("Can't include!");
} else {
return true;
}
}
function secondaryAutoload($class) {
include('library/' . $class . '.php');
}
spl_autoload_register('genericAutoload');
spl_autoload_register('secondaryAutoload');
Expected result:
----------------
Autoloaders added later on in the code would be called first, so the
stack would be called in the reverse order it is now, or new autoloaders
would be prepended to the autoloader stack. This would allow the first
initial autoloader to error out as the last catch-all, but subsequent
autoloaders to accomodate particular scenarios, where they would most
likely not produce a total failure. The reproduce code will show an
instance where the secondary autoloader will never be called because the
first autoloaderis called and designed to fail if a file cannot be found
for the given class.
--
Edit bug report at http://bugs.php.net/?id=42823&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42823&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42823&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42823&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42823&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42823&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42823&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=42823&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=42823&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42823&r=support
Expected behavior: http://bugs.php.net/fix.php?id=42823&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42823&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42823&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42823&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42823&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42823&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=42823&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42823&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42823&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42823&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=42823&r=mysqlcfg
