Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:16969 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43302 invoked by uid 1010); 28 Jun 2005 21:27:35 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 43287 invoked from network); 28 Jun 2005 21:27:35 -0000 Received: from unknown (HELO safesearching.com) (127.0.0.1) by localhost with SMTP; 28 Jun 2005 21:27:35 -0000 X-Host-Fingerprint: 209.151.233.33 unknown Linux 2.4/2.6 Received: from ([209.151.233.33:49178] helo=mail.safesearching.com) by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP id D2/83-00424-7C0C1C24 for ; Tue, 28 Jun 2005 17:27:35 -0400 Received: (qmail 5773 invoked from network); 28 Jun 2005 21:45:06 -0000 Received: from adsl-67-112-238-195.dsl.lsan03.pacbell.net (HELO ?192.168.1.137?) (james@safesearching.com@67.112.238.195) by mail.safesearching.com with RC4-MD5 encrypted SMTP; 28 Jun 2005 21:45:06 -0000 Message-ID: <42C1C1D3.7060601@safesearching.com> Date: Tue, 28 Jun 2005 14:32:03 -0700 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: class_exists and __autoload From: james@safesearching.com (James Crumpton) I opened a bug (http://bugs.php.net/bug.php?id=33459) to report an issue with the default behavior of class_exists calling __autoload in PHP5. The bug was marked as bogus, and basically stated that it's PEARs problem. After responding, the bug can now longer be searched for. I believe this still requires some attention as the issues around it are very similar in nature to the ones with instanceOf and __autoload. (See http://news.php.net/php.internals/16746) Basically, adding __autoload to any script using Calendar/DB_DataObject/SOAP/Validate (just to name a few) will throw a fatal error. Example being: This isn't specific to PEAR however... any script/class that uses !class_exists() to load a file not in 'include_path' will fail when __autoload is used in conjunction. Furthermore, I fail to see why such a "feature" is in place when it makes all existing if(!class_exists()) {} constructs worthless. if (!class_exists($className)) { // ... do something interesting ... // well, with autoload defined, this block will never be reached. // autoload will either load the class and the above condition will // be false, or autoload will throw a fatal error and we never get here } I just don't understand the logic behind throwing a fatal error when I'm writing code to try and prevent one from occurring. I realize a second parameter is available to class_exists that can be set to false, which will prevent __autoload from being called, but developers don't always have the luxury of modifying other peoples code to make it work they way they intended it (such is the case with PEAR classes). If someone really wants this behavior (though I can't understand for life of me why), then allow them to pass TRUE as the second parameter, but leave the default be false. Or at the very least let autoload return false, so that the rest of the script can do it's thing... or maybe allow for a php.ini option to set the default behavior to false (though this option can make some scripts less portable). -james