Re: [Coding Standards] Loading all files at once

Matthew Weier O'Phinney wrote: > On 7/12/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote: >> > >> > * 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) >> >> I do not think that the impact is debatable at all to the "speed >> freak" faction. Modification of code at install time is not the way >> to go. It will cause all sorts of uncertainties during deployment > > Certainly, 15% is a sufficient enough gain to warrant making a change. > However, whether or not this should be the job of PEAR instead of a > build tool is debatable. Build tools are much better suited for this. > >> and it of course does not fit the unzip and go crowd. >> >> Speaking of unzip and go, we should teach the package command to do >> all possible file rearranging before the tar to further ease the life >> of unzip and go people without loosing the ability to move files into >> different locations than where they are in CVS. > > 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). > > Keep the standards as they are, but have tools available to suit the > various target audiences. > Just one note, a build tool would only be able to clean up require_once, if the way require_once is used is strictly standardized to allow such stripping. There are far many different ways some of the current factory methods work, including using include_once, and custom findFile(), classExists() methods and the like. -Philippe