Re: Why change require_once? A brief explanation of motives

Matthew Weier O'Phinney wrote: > I think this is a reasonable goal. I'm not convinced that removing > require_once is the solution, however. > > Frankly, I'm seeing an RFC that does the following: > > * Trades one known and widely used language construct, require_once, > for another, autoloading; > * with the purpose of saving 15% of a fraction of the execution > overhead; > * and solving an edge case of installation (phar); > * and making tracking down *where* and *when* a class file is loaded > much more difficult. > > Basically, I think that while the goals of the RFC are well-stated, the > *whys* behind them have not been (or have not been backed up with > sufficient evidence), and that they have neglected to consider other > elements of the equation. > > All that said, I'm not totally against this any more. Like Paddy, I'm > coming around. I just think that there's more discussion needed, and > more honesty and transparency from all parties. Hi Matthew and all, You will find my annoyance level quite high when words like "honesty" are thrown about as if there is any lack of honesty. This kind of insinuation is what often makes me lose interest in participating in open source, if only for a moment. Let me be quite blunt: where the lies at? The truth is that I have been bouncing these and other ideas off of many developers off of pear-dev for a while, and gradually expanding the circle of people I talked to about them in order to refine them and get a better sense of both the advantages and especially of the problems. Yes, many of my ideas have been cut from the RFC over time, this is how team and real community collaboration works. In addition, lots of tweaks or new ideas from others have made their way into the RFC. Arnaud is the official RFC sponsor from the PEAR group, and his (it turns out rather naive) assumption was that by presenting the RFC in its current state, you developers would be capable of examining it from the same perspective that he and other PEAR group members examined it, as a new idea to be considered rationally and carefully, to be questioned and taken as a work in progress. Now, for technical stuff: the RFC does not trade require_once for autoloading, it removes require_once in favor of giving users the flexibility of choosing whether to use three possible ways to load class files: 1) include allfiles.php and start using the app 2) use include_path and autoload 3) require full path for needed files, or some other customizable solution In addition, by removing hard-coded require_once statements, it allows the mega-speed freak to do the ultimate optimization: mash all the needed files into a single php file - WITHOUT code modification, which also means that upgrading the contents of the file is a simple task (no need to muck about for new require_once statements added in the code contents for some new driver implementation or whatnot). I am out of time, so I must send this message. Please understand that I have about 1 hour every 4 days in which to send messages, I can read messages every day though. I can't give you and PEAR anything more until mid-August, I'm very sorry about this!! Thanks, Greg