Re: on the coding standards - Re: [PEAR-DEV] PEAR Group June 24 2007 Meeting Minutes

Joshua Eichorn wrote:

You can also easily use a phing script to generate customized include files for you packages and in PEAR2 approach you don't have to munge every file. Hopefully PEAR2 would be to have some tools, at least for generating custom include files for packages like MDB2 with driver subpackages.

The opposite could be said as well when generating packages to install. Pyrus and/or phing could be employed to add a dirname() to every require_once that matches your packages base directory. When you run "pyrus package", it should be building for the various distribution channels, not the code making itself behave better that way. MWOP put it best in the discussion on the wiki: "Using class_exists() hacks and loading all files regardless of being used is coding for tools, not coding for PHP." MDB2 is an excellent example of a package that's going to load a lot of cruft, unless you have two requires: require_once 'MDB2/allfiles.php'; require_once 'MDB2/<driver>/allfiles.php';

The goals of the require_once changes are (there may be other things too, this is just what I remember as the big items): make the use of __autoload possible

Doesn't this contradict point 2 since based on recent discussions it seems that __autoload() is impossible to cache? ;-)

be opcache friendly

I've heard this in a lot of places, but what #s are being used to say it's opcache friendly or more opcache friendly versus every file having a lot of requires and having a bunch of duplication throughout the code? Someone has either 1) run tests to come to this conclusion, or 2) is talking out of a rear orifice. I know quite a few of you guys, so I'm assuming the former is the case. :-) If the benchmarks have be run, I think posting them as supporting material would be quite useful in helping people make an informed decision. Note: I just read through your posting to the discussion from last fall that Rasmus took part in. I would still like to see tests run to provide actual #s. I know when I've benchmarked code before to see what was faster, I almost always get a surprise somewhere in the results.

make it possible to use PEAR without messing with your include_path

See my comment above about building the package to match the distribution channel.

make it easy and consistent for new developers to get started using a pear package (just include the packages allfiles.php and your good to go)

This I can agree with to some extent, but don't make it the requirement. Instead, have Pyrus generate one of these when it installs the files/creates the package. This gives someone a short-cut to get the package up and running, but gives someone looking for performance to load the objects of a package on an as-needed basis while still having each object within the package capable of loading what it needs. require_once on any sort of server level disk isn't really that slow. In the profiling I've done of some rather large PHP applications with no opcode caching, the use of require_once isn't even a blip. To me, that makes performance look like a non-starter. Making things easier I can go with. Though an argument could very easily be made that you're just making things easier for people to design in-efficient code (i.e., PEAR2 sets the "everything and the kitchen sink" example). -Travis