|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2005-06-24 05:37 UTC] 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 PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Thu May 16 16:01:34 2024 UTC |
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.