Re: Why change require_once? A brief explanation of motives

Hi, Greg Beaver wrote:

I've been barely following the tremendously long thread on the proposed coding standard changes. Needless to say, I wish that people would approach these from a perspective of assuming goodwill from the PEAR Group and the PEAR president, but I do understand that this is a difficult assumption to make, as one should be suspicious of anyone in power for good reasons.

They also say that the road to hell is paved with good intentions.

1) EVERY existing PEAR package will continue to both install and work, but packages that use PEAR_Config or PEAR_Registry directly will not function properly. Replacements will continue to work, nothing is changing here. (P.S. haven't you all learned by now I'm a BC freak?)

OK, so a question: will I be able to continue developing my packages for the current standards and ignore all PEAR2 idiocy?

2) The suggested changes to usage of require_once in PEAR packages are a radical new idea and do require rational and careful evalution. I must say I am extremely dissapointed with the response so far. I have to encourage every person who has posted FUD without any investigation to in the future please try to back up any posted information with facts, or at the very least links to messages from the archives. Most installer-related conversation is on the pear-core@lists.php.net mailing list, and I have been discussing these changes there for over a year now. As benchmarks have shown, and both Gopal and Rasmus have blogged about, require_once is a major problem for APC and other optimization systems because it forces several stat calls. require_once with relative path makes this even more difficult. On FreeBSD, for instance, stat is a very expensive system call, and can result in being a more significant bottleneck for PHP applications than database access. Gopal has blogged extensively about APC and require_once at http://t3.dotgnu.info/blog/php/. In addition, one of the huge problems APC has encountered is with HTML_QuickForm's require_once "loops" where drivers require_once the base class, and everything is loaded later, requiring incredibly complex logic to resolve caching of class declarations at compile-time. This is not to single out HTML_QuickForm, but instead to note that may PEAR packages are in fact the source of an unnecessary complexity that makes it almost impossible to use an opcode cache to improve the efficiency.

That was very nice of you to provide a link to Gopal's blog, since I immediately found an interesting post there, titled "include_once mostly harmless": http://t3.dotgnu.info/blog/php/include_once-mostly-harmless.html Quoting: "With the release of APC 3.0.14, there is a decent workaround which doesn't require any changes to the php code." "Essentially it converts all relative path includes, such as those from the pear paths, into absolute path includes. This works well with the stat=0 mode because file modifications are ignored after caching." So, a question: where is an official benchmark of PEAR with APC 3.0.14 with all relevant optimisations (apc.include_once_override on and apc.stat off)? I only saw much handwaving and links to Rasmus's talk which was given long before APC 3.0.14

In addition, the use of require_once automatically limits PEAR packages to use on disk. phar archives are required to modify the source in order to use the package, resulting in a significant possibility of accidental error introduction when post-processing the source.

Building of a phar archive (if one is really needed, which I doubt in most cases) is a job of a build tool.

Finally, setting up include_path has proven again and again to be a major issue, and not just for beginners, as has been asserted in many (rather condescending) emails written in response. I don't think many would consider me to be a beginner, but I regularly run into include_path issues with my development on the PEAR installer. Many times, the installer finds itself accidentally including an older version of PEAR simply because the include_path is set up incorrectly. The same issue has affected my usage of Chiara_PEAR_Server and many many other scenarios. include_path is not a bad thing, I happen to love it, but that doesn't mean I always want to rely upon it. Sometimes, when setting up a "do-this-today" application, I'd rather prototype something that "just works" and then later properly set up an include_path environment, something that is physically impossible with the current PEAR library design.

Greg, people who argued about include_path talked about *using* PEAR packages, not *developing* them. Please do not try to shift the discussion. Of course you can have problems if you have several copies of packages in various stages of completeness, but that's not the case for 99% of our users who only set up packages via PEAR installer. That *will* be the problem for these users, BTW, if we allow using the packages without installing them.

The new coding standards are designed to eliminate these problems all at once. There are two separate approaches to this: Thing 1 ======= Eliminate require_once 1) use class names without loading the files containing them 2) provide an autoload mechanism (PEAR2_Autoload) 3) provide a "it just works" file that can be included to quickly use a package (allfiles.php) Thing 2 ======= Better document what is needed 1) use a graceful if (!class_exists('name', true)) for reporting missing dependencies 2) make sure all files needed are listed in the comments at the top of each file 3) add a README file to each package Thing 2 is probably best done as a recommendation, although #2 (document dependencies) is a must-have. Note that every PHP user is used to their own pet project's methods, i.e.: require_once 'Relative/Path.php'; require_once SOME_CONSTANT . 'Relative/Path.php'; Slow_Loader::Load('Classname'); As many benchmarks have shown, all of these are slower than the simple approach the standards recommend. More importantly, they are inflexible. The most common complaints about PEAR are (in order)

Where are results of these many benchmarks? As stated above, I'd like to see these for APC 3.0.14 with all optimisations on. Also your Slow_Loader::Load('Classname'); is *the* most flexible, as it completely abstracts the loading of class and does not require any "magic" like __autoload().

1) you have to install things

you'll have to manage dependencies manually

2) you have to set up include_path

you'll have to manage paths manually

3) there's base classes required that are all non-PHP things (PEAR and PEAR_Error)

non-issue with E_STRICT packages. you'll need a PEAR2_Autoload in PEAR2, though.

4) bloat

you do know yourself that it's mostly FUD, right? so why are you repeating it here?

What is really involved for you all? Change you code like so: <?php require_once 'Another/Class.php'; class Blah extends Another_Class { } ?> to this: <?php /** * This needs the Another_Class package, located at http://pear.php.net/pear2/Another_Class */ class Blah extends Another_Class { } ?>

So the people who are now unable to read error messages thrown by PHP / PEAR will need to read freaking comments? Puh-lease!

note that I made up the URL, I have no idea what it will actually look like for PEAR2. Users would simply need to either use allfiles.php, autoload, or if performance is an issue, they can do: <?php require '/full/path/to/Another/Class.php'; require '/full/path/to/Blah.php'; ?>

Why don't do this via installer, then? @pear_lib@ -> '/full/path/to/pear/' Oh, yes, we are trying to reduce the number of replacements and make people do everything manually.

and they are good to go, and can turn off APC stat and have efficiency - ALL interested parties win, use of PEAR skyrockets, and we get a crapload of new developers in the process to improve things.

And we get a crapload of developers who go the way of PHPUnit, most likely. Some of them even manage packages with 6-figure downloads.