[wp-trac] [WordPress Trac] #13436: WordPress class_exists() conflicts with __autoload() and php_auto_prepend

[WordPress Trac]

#13436: WordPress class_exists() conflicts with __autoload() and php_auto_prepend
-------------------------------+-----------------------
 Reporter:  galbus             |       Owner:
     Type:  enhancement        |      Status:  reopened
 Priority:  normal             |   Milestone:  4.0
Component:  Bootstrap/Load     |     Version:  3.0
 Severity:  minor              |  Resolution:
 Keywords:  needs-patch close  |     Focuses:
-------------------------------+-----------------------

Comment (by rmccue):

 Replying to [comment:21 jcjcc]:
 > I didn't write my own autoloader -- this is the PHP default autoloader!

 I'm personally still OK with leaving this issue as is. PSR-4 explicitly
 notes "Autoloader implementations MUST NOT throw exceptions, MUST NOT
 raise errors of any level, and SHOULD NOT return a value" as noted by
 Denis. It's certainly OK for SPL to throw exceptions, but it's not PSR-4
 compliant, and I don't think we need to support anything non-compliant
 with that (even in SPL).

 That said, I cannot reproduce this error with the following:

 {{{
 spl_autoload_extensions('.php');
 spl_autoload_register('spl_autoload');

 var_dump(class_exists('Testing'));
 var_dump(class_exists('\\Testing\\Foo'));
 }}}

 (PHP 5.4.9)


 > But that's besides the point -- class_exists is documented to *throw an
 error* if the class cannot be loaded (it has nothing to do with
 file_exists...) and the second parameter is true (which is default). Thus,
 the code as it is right now is incorrect.

 I'm not sure where you're getting this from; the
 [http://php.net/class_exists documentation for class_exists] does not note
 this. `class_exists` is meant to return a boolean that indicates whether
 the class exists or not; a class not existing is not exceptional
 behaviour, so it shouldn't throw an exception. Doing so is a weird quirk
 that I'd argue is a PHP bug (albeit one we may need to work around for
 pragmatism's sake).

 > I don't understand rmccue's "code churn" argument.

 Basically, I'm arguing against changing just for the sake of it. It's the
 same reason we reject whitespace-only fixes: if it ain't broke, don't fix
 it.

 ----

 For what it's worth, I use autoloaders extensively on every project I work
 on with WordPress, and I've not hit any problems with it.
 [https://gist.github.com/rmccue/e03d99d04e1db8ab06a6 Here's the one I
 use], for reference (consider it GPL). As long as you stick to the PSR-4
 rules, you won't hit any problems.

 It's worth mentioning that any project expecting PSR-4 compliant
 autoloading will likely have the same issue.

 I still recommend close.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/13436#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform