Re: [Coding Standards] Loading all files at once

Howdy all... Christian Weiske wrote:

If the 'pear package' command could create allfiles.php, a build tool could then later strip out the require_once commands from the various files. This would then suit those who want unzip-and-go (as allfiles.php is present), those who want to keep it in the include_path (require_once calls that utilize the include_path for resolution), and those who need optimization (build tool to strip out *_once calls).

If you use allfiles.php, you need to strip out all require_once calls - which isn't feasible for the unzip-and-go approach. Also, modifying files on installation is bad, because doing this, there will be dozens of different error sources, and bug tracking will begin with 'which installation options did you use?' because the installed files are not guranteed to look like the ones the developer uses to track down the bugs.

Christian, I have to disagree with you here. The thing that keeps getting missed is that the unzip and go package is created by the package lead/developer. When I create it via 'pyrus package-zip' (or whatever), Pyrus will do all of the adjustments at that point, then that package can be distributed in a ready to use format. It's also worth noting that stray require_once calls are faster than doing an if(!class_exists()) check. In any event, the fact that the code will be harder to keep track of is a red herring. This is what unit/functional tests are for. The tests just need to be pointed to the different releases, then run and you've got a pass/fail that'll show you exactly what is required to make it work. Based on the "modifying files on installation is bad" theory, Pyrus should drop the concept of tasks completely as that's their sole purpose.

Further, complicated things like conditional includes cannot just be stripped out from code while guranteeing that the code does not break.

Conditional includes should only exist within set criteria such as loading a little used driver. This is something to take up with the design of each package on a per-case basis. In some cases, there will be little or no reason to actually have the conditional include; in others, it will be the only way to make it work. In the case where it needs to be absent when using allfiles, surrounding the code with "// STRIP ALLFILES" or some similar token will ease the process of removing code that's not necessary for the given package. -Travis