Re: Why change require_once? A brief explanation of motives

Hi Greg, I actually dug around all the threads, and after tracking forward quite a bit I finally came to the conclusion the changes make sense - your email helps too. The only notable concern I have is implying that the end user will be capable of defining an __autoload(), or using the SPL register functions for a PEAR provided autoloader function. This will in all likelihood become the new include_path support request. Clear and obvious documentation could help here - maybe a few obvious pointers somewhere else outside the docs. I think it's interesting it took so long to convince me. I'm not an inexperienced programmer. I'm as open to a good idea as anyone. It seems, as a newcomer (ze n00b!) lurking on the outside of his first contentious PEAR discussion that the RFC appeared in isolation, materialising from some unfathomable process. My lack of knowing the PEAR way of doing things may be telling though ;), only been tracking things for a short while. But there was so much reaction to it that it looked as though nobody expected it. It's a list of suggested practices without explanation, method or reason mentioned anywhere inside - an RFC lacking a clear purpose, or at least none an idle reader like me could locate. So I have to say this long thread is the result of poor communication - with respect :). The post you just made is something that could have been made right at the very start - clearing up any obvious misunderstandings we've circled the past week or so. May I suggest that the RFC, when updated, clearly note the critical "why?" of each proposed change and elaborate on how the alternative will have dire consequences? Also for any terms not in common usage, provide a clear definition. In my opinion (as the n00b!) this would avoid a lot of the questioning, misunderstandings, and, yes, FUD, this thread has seen. It would also lower resistance to changes, once people have sufficient facts to hand to make an informed opinion. Kind regards, Paddy Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Greg Beaver <greg@chiaraquartet.net> To: PEAR developer mailinglist <pear-dev@lists.php.net> Sent: Tuesday, July 17, 2007 2:07:11 AM Subject: [PEAR-DEV] Why change require_once? A brief explanation of motives Hi all, 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. I have extremely limited time to explain where these ideas come from, but let's just say that they come from many long hours and many long months of careful research. First of all, anyone wishing to know what is planned for Pyrus, the installer for PEAR2 should check two locations, the source code at http://svn.pear.php.net and the roadmap at http://pear.php.net/bugs/roadmap.php?package=PEAR Here is a short list of things that are REALLY important to understand: 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?) 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. 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. 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. 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) 1) you have to install things 2) you have to set up include_path 3) there's base classes required that are all non-PHP things (PEAR and PEAR_Error) 4) bloat To eliminate #1, I have provided several things in the installer, but they do require that libraries make changes to the way things work like eliminating replacements. For #2, The require_once requirement has to go. #3 means we are never going to have another base class named PEAR2 or PEAR2_Loader - the inflexibility will make embedding PEAR2 libraries harder than it is to embed PEAR libraries now. Finally, #4 means we have to allow people to selectively include portions of a package, which the proposed solution does in fact allow. 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 { } ?> 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'; ?> 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. I am happy to discuss any of the proposals and change them, but please limit your comments to brief and carefully researched comments, FUD is extremely discouraging and does not help us solve the problems at hand. Thanks, Greg -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC