Re: [Coding Standards] Loading all files at once

Hi, Joshua Eichorn wrote:

This sentence from the Introduction of the document is a big reason behind the change: The new PEAR2 repository of code is designed for both installation by the Pyrus installer and unzip-and-go. There are existing rules in the PEAR repository which need to be revised. This document itemizes all the changes. The important word is "unzip-and-go". unzip-and-go requires that PEAR2 to be at least optionally include_path independent. If there is a better solution then allfiles.php to make that work i'm all for it. I'm even testing various options and benchmarking them. But the current system has problems, I'm not suggesting we change it because it sounds like a fun thing to do. I'm hoping to get some benefits here.

Unzip-and-go is useful for applications (PhpDocumentor) but not for libraries! In case you forgot, phpDocumentor currently bundles a custom version of HTML_TreeMenu and Smarty. It is no problem, as you don't include phpDocumentor files, but just run the application. Now, what happens when I distribute HTML_QuickForm2 as unzip-and-go? Will I need to bundle HTML_Common2? Or will the user need to resolve dependencies by hand? What happens when he unzips-and-goes another package which needs a different version of HTML_Common2 (I'm not talking BC breaks, I'm talking feature additions)? Way back, when PEAR installer was a steaming pile of shit unable to resolve dependencies, lots of HTML_QuickForm errors on pear-general were caused by "unzip-and-go", there is even a FAQ entry http://pear.php.net/manual/en/package.html.html-quickform.intro-faq.php#AEN60092 Unzip-and-go is not a solution, it is a huge *problem* for libraries.

Make sure PEAR2 is fast in opcache environments (this being the people who care most about performance)

"Current PEAR is slow in opcache environment. Here is the data to back it up."

Make sure PEAR2 truly works with __autoload (some people like autoload)

__autoload() is a user function outside of PEAR2 control. A sufficiently broken implementation can and will break PEAR2, too. Therefore we can't promise that PEAR2 will truly work with *every* __autoload().

Make it very easy to start using a PEAR package

"It is currently very hard to start using a PEAR package because..."

Make it possible to do super custom stuff like using PEAR in a phar You may disagree that these points are important, but I do hope you understand that there is some a reason for me wanting some change here.

Yes, there (probably) is some reason. The point is, you didn't present this reason.