Thank you for your report.

I do not think the behavior you describe is a bug. The documentation is clear about this:
"If your code has an existing __autoload function then this function must be explicitly registered on the __autoload stack. This is because spl_autoload_register() will effectively replace the engine cache for the __autoload function by either spl_autoload() or spl_autoload_call()."

Thus, calling spl_autoload_register() replaces __autoload().

My code doesn't use __autoload.

My code uses spl_autoloload.

I have received a bug report because my code has destroyed an existing library.


By issuing this bug report I have asked you to stop this, by either:

* deprecating __autoload altogether

* fix spl_autoload to honor an existing __autoload or

* let library authors check for an existing (or upcoming) __autoload so that their 
library doesn't destroy existing code

With the current behaviour I have no other choice but to not use spl_autoload at all, 
since I don't know whether the user will or will not include a library which uses 
__autoload later on.

If two or more of the libraries use __autoload, it won't work, and there is nothing anybody can do about it.

If all of the libraries use spl_autoload_register, it works as it should.

If one of the libraries uses __autoload and others use spl_autoload_register, it is the task of the library that uses spl_autoload_register to register __autoload as well, like this:

if (function_exists("__autoload")) spl_autoload_register("__autoload");

> if (function_exists("__autoload")) spl_autoload_register("__ autoload")

Doesn't work. In line 7 __autoload is not yet defined.

Note that every line in the given example comes from a separate include()d php 
library.

This is a link-time problem which only php can resolve: it must save a legacy 
__autoload handler before creating the spl_autoload stack and call the legacy 
autoload after all other registered spl_autoload hooks.

So the problem occurs with:

include('spl_autoload_register.php'); // uses spl_autoload_register
include('autoload.php'); // defines __autoload

Right. In particular: 

<?php // pjb library
function autoload_pjb($x) {echo "pjb "; return false;}
spl_autoload_register("autoload_pjb");
if(function_exists("__autoload")) spl_autoload_register("__autoload");
?>
<?php // joomla library
function __autoload($x) {echo "joomla "; return false;}
?>

<?php // application
require("pjb.php");
require("joomla.php");
@new Foo();
?>

Please see the link posted with the bug report for all the details.


However, I think neither the user nor joomla nor I have to invent strange 
workarounds for bugs in the php implementation. Any new introduced PHP feature 
must be compatible with earlier PHP features, unless the earlier features have been 
deprecated and a clear migration path exists.

The old __autoload is neither deprecated nor is spl_autoload_register compatible with 
it. Whoever wrote it and the comment "....This is because spl_autoload_register() will 
effectively replace the engine cache fo the __autoload function by either 
spl_autoload()  or spl_autoload_call(). "  wrote a bug.


> Thus, calling spl_autoload_register() replaces __autoload()

If spl_autoload_register is intended to replace the old __autoload machinery, the old 
__autoload should have been deprecated and a clear migration path should have 
been given to those using it.

There is no way to "fix" this in PHP.

__autoload in itself is not deprecated, but it is not a good idea to use it as part of a library, for obvious reasons. However, if you know your code will only have one autoload function, using __autoload will be just fine.

To me it seems that the library writers that still use __autoload are at fault here.

How about that (php 5.3):

<?php
spl_autload_register(function($class) {
if (function_exists('__autoload') 
__autoload($class);
})

> Please either deprecate __autoload […]

__autoload() is deprecated as of PHP 7.2.0 and will be removed in
the next major version, see
<https://wiki.php.net/rfc/deprecations_php_7_2#autoload>.