Re: Why change require_once? A brief explanation of motives

Matthew Weier O'Phinney wrote:

Better would be: if (!class_exists($class_name)) {

       throw new Exception('Unable to load');

} return new $class_name; as this would not depend on the function __autoload() being defined, but would utilize autoloading if available. It's basically the same as the recommended practice in the RFC at this point, but within a userland factory.

See my other reply to Johannes, this precludes having nice error handling.

The original complaint was that __autoload and spl_autoload do not allow you to throw an exception if the class file was not found, and instead raises an E_FATAL. The example you show here pushes the checks into the library code, which is fine for factories, but a PITA when it comes to class files: do I really want a conditional for each and every class my class depends on? whan impact will this have on performance (class_exists() tests are slower than a single require_once as instead of being a language construct, you now have a conditional, a function call *and* the include statement).

No for normal code, I would expect a E_FATAL error to be thrown.

Now the "ugly" part in all of this, is something we have been debating on this list before without a proper agreement. The first one is the fact that in order to prevent those warnings, you would have to suppress the include with an @ or you would need to attempt to find the file in the file system first, which is harder than one would hope for when relying on the include_path, since internals does not think we need an include_path search parameter in file_exists() like is available in fopen().

In Zend Framework, we actually created an isReadable() implementation that searches the include path for this very reason -- something that feels like a needless hack.

It is a hack. Basically you can either fopen() or loop over the include_path setting, just as much as hack. BTW: Why wasnt this called isIncludeable()?

Sure, having the require_once calls in the class files when autoloading is present may seem redundant, but I still haven't seen conclusive test results that show any significant performance benefit to removing those calls (other than perhaps on FreeBSD -- but Greg doesn't indicate whether or not those tests were done before or after the realpath cache was added in the 5.2 series).

Because the require_once calls force loading of code that may not actually be used. Furthermore as you point out its a non free function call. regards, Lukas