Re: Why change require_once? A brief explanation of motives

On 7/20/07, Greg Beaver <greg@chiaraquartet.net> wrote:

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.

Greg, I'm truly sorry if I offended. However, what you write below and what I write above are still not meshing. Let me explain, inline:

Let me be quite blunt: where the lies at?

I'm not claiming there is any lying going on. I'm simply claiming that not all motivations for the change are being fully spelled out, and also that those authoring the changes are not necessarily listening to the dissent that's occurring.

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.

Greg, those of us critiquing the RFC are doing *exactly* what you suggest: critiquing and questioning the new ideas. The problem is that the list, as presented, does not provide any sort of empirical evidence that shows that (a) the problems cited exist in current PHP and APC versions, and (b) the solution provided takes into account all concerns (and not

       just the list you present, but also those raised by others in
       examination of the RFC).

How are we supposed to evaluate this in any rationale way without either of these being explicitly addressed? And no, the "technical stuff" you present below does not address any of this; it's just the same comments that have been slung around over and over again in this thread. I realize that *you* may not have time to address the concerns myself and others raise, but surely you can delegate this to other members of the PEAR group? This is the transparency I'm asking for: please answer (a) and (b) as I've presented them

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

What about (4) Use include_path without autoload? Many people shy away from autoload as adding a level of magic that makes debugging difficult.

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 and others contend that this is the purpose of a *build tool*. Phing is perfectly capable of this task, and most developers who are looking for this sort of optimization can probably script this practically in their sleep. If there are explicit guidelines on how to code your classes to make such scripting easier (such as checking for !class_exists() prior to doing a call to include/require_once in conditionals, instead of simply calling it), then PEAR2 can make this type of automation even easier. I feel that this debate is like two ships passing at night: neither party is listening to the other. For those of us dissenting, it feels like the authors and proponents of the RFC are simply trying to ram it down our throats without listening to our concerns; for the authors and proponents of the RFC, I'm sure we dissenters sound like a bunch of whiners who aren't willing to change. (BTW, those who know me and how I code should know how false that impression is. I'm constantly trying to better my coding skills.) I'm truly willing to entertain and adhere to the RFC *IF* somebody is willing to answer the questions I and others have raised, and (heaven forbid) to possibly even listen to and entertain some of our ideas (e.g., why the heck *shouldn't* build tools be used to solve some of these issues?) So, again, I'd like to see *EMPIRICAL EVIDENCE* that: (a) the problems cited in the RFC exist in current PHP and APC

       versions, and

(b) the solutions provided take into account all concerns (and not

       just the list presented, but also those raised by others in
       examination of the RFC).

I do not expect you, Greg, to do this personally. But at the least, please delegate this to others in the PEAR Group supporting the RFC so that we can lay this to rest. -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/