Re: [Coding Standards] Loading all files at once

Matthew Weier O'Phinney wrote:

From what I'm reading, I'm seeing the following: * It's hard to verify that require_once is or is not the bottleneck, as results vary based on environment and methodology * Regardless, the performance gain, if any, is not huge * Many are upset with the proposal, on many grounds including: * seems like a rewrite of PHP (!class_exists() hack) that could lead

     to a situation similar to the PEAR::isError() situation (i.e., if
     PHP changes to be more performant or correct the situation, new
     standards and changes would need to be made, whereas using
     existing PHP functionality would not)

* premature optimization * coding for tools (phar, etc.), instead of adapting or creating

     tools (installers, converters, etc.) to perform the optimization
     tasks from existing sources

* many projects use the existing standards, and PEAR stands to lose

     its position of leadership if they disagree with the new standard
I agree that those are all good reason to keep the current system.  I don't agree that allfiles obfuscates the code, which was my last reply.

Of course I still think the current system has poor usability that many people are just ignoring but there are lots of ways to solve that, including things you've suggested.

On a final note, it feels to me like the principal authors of the draft specifications in question are not listening to the community, but rather pushing their own personal agenda. Please let this be a community process. I'm also not the author of this draft you can tell this by looking at the author line at the top, or by the change history in the wiki.

A number of individuals have proposed that the generation of allfiles.php and/or removal of require/include_once calls be done by the installer, and I think this idea is excellent -- particularly if there are options *not* to do these actions. This would serve the purposes of all three target audiences (as defined by Lukas), and not require a change to the actual CS. Yep i've talked with a lot of people about this and this may well be the best approach.

Generation of allfiles.php is actually pretty hard to do since order can matter but its not unsolvable.

Additionally, the idea of a PEAR2_Loader class that can initialize/manipulate the include_path, load classes, and register with spl_autoload seems like a no-brainer. Some of this sounds reasonable but i don't think anyway wants to replace require_once with a method call.

I'm also not sure that a utility class for playing with the include_path should be included in the pear2 standards. Though it is code that should be written, and i can setup SVN access for someone who wants to write an alpha version.

I respectfully ask that the draft be revised to incorporate these ideas.

A good place to start would be to propose some actual language for what your thinking. -josh