Re: Why change require_once? A brief explanation of motives

On 7/17/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:

Matthew Weier O'Phinney wrote:

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()?

Because it's not just for include and require, but to check if any file in the include_path is readable.

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.

So encourage lazy-loading instead of indiscriminately loading every single dependency at the top of the file. Last I recall, during the PEPR review process, most reviewers suggest this anyways. I'd like to see recent and reasonable benchmarks, please. -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/