php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #33459 default behaviour of class_exists/__autoload() breaks PEAR classes (and others)
Submitted: 2005-06-24 05:37 UTC Modified: 2005-06-25 00:33 UTC
From: james at safesearching dot com Assigned:
Status: Not a bug Package: Feature/Change Request
PHP Version: 5.* OS: *
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: james at safesearching dot com
New email:
PHP Version: OS:

 

 [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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-06-24 15:23 UTC] helly@php.net
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-25 00:33 UTC] james at safesearching dot com
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 23:01:28 2024 UTC