ID: 33459
User updated by: james at safesearching dot com
Reported By: james at safesearching dot com
Status: Bogus
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.*
New Comment:
I fail to see how a change (that doesn't really make sense in the first
place) implemented by the PHP group at the request of some outside
organization is the problem of said organization.
If the PHP group makes a change (regardless of whoever requested it)
that breaks BC with existing scripts, the problem falls squarely on the
PHP group.
If the current behvaiour is to be left in place, then the documentation
needs to clearly state that the use of __autoload in conjuction with
older scripts using class_exists can cause problems.
Alternatively (and perferably), the end user should be given some level
of greater control when using __autoload. Examples being: a) a php.ini
option to allow users to set the default behaviour of class_exists, b)
a way to return from __autoload that doesn't generate a fatal error:
function __autoload($name) {
if (in_array($name, $ignoreList))
return true;
require_once($name);
}
c) allow class_exists($name, TRUE) to call __autoload (as opposed to
FALSE)
When it gets down to it, it doesn't make sense to "throw a fatal error
when you're writing code to avoid a fatal error." Refer to
http://news.php.net/php.internals/16746 to see a discussion regarding a
very similar (same?) problem with instanceOf.
Previous Comments:
------------------------------------------------------------------------
[2005-06-24 15:23:45] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
That's not a problem of PHP but a problem of PEAR not taking care of
PHP 5 and their own requests for PHP 5.
------------------------------------------------------------------------
[2005-06-24 05:37:07] james at safesearching dot com
Description:
------------
The default behaviour of class_exists calling __autoload breaks BC for
end user scripts which rely on other code outside that users control
(ie PEAR classes).
Many PEAR classes such as Calendar and DB_DataObject use class_exists
to load other classes...
Simply adding an __autoload function to a script using these classes
generates a Fatal error.
An option was added to allow a class_exists($name, FALSE) call to
prevent an __autoload call... but as end users don't have control over
things like PEAR classes, this isn't a viable fix to bug #28333.
Perhaps more reasonably, class_exists should not call __autoload by
default so as to maintain BC... and allow users to explicity request
that behaviour with a second parameter of TRUE.
Reproduce code:
---------------
require_once('Calendar/Calendar.php');
$cal = new Calendar();
function __autoload($name) {
require_once($name);
}
Expected result:
----------------
Expect no output (ie no errors).
Actual result:
--------------
Warning: __autoload(Calendar_Engine_UnixTS): failed to open stream: No
such file or directory in /home/james/test.php on line 8
Fatal error: __autoload(): Failed opening required
'Calendar_Engine_UnixTS' (include_path='.:/usr/local/lib/php') in
/home/test.php on line 8
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=33459&edit=1
