Re: [Coding Standards] Loading all files at once

Travis Swicegood wrote:

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.

I was not aware that the intention was to have a separate package for unzip and go people. I thought that the unzip and go would actually be an untar and go and we would work on having Pyrus do as much of any reorganizing and variable subtitutions as packaging time instead, so that people can take a PEAR package and untar or install.

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.

Pushing this maintenance issue to unit tests is like handing a junkie a gun while sweet talking him not to shoot you for the heroin in your pocket. regards, Lukas