Re: Why change require_once? A brief explanation of motives

Hi Greg, I would like to reiterate that for some of us, the plot is at this stage getting repetitive. The RFC needs updating, in my humble opinion, before this discussion can go anywhere. >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. Matthew picked words badly perhaps, but the intended meaning was I assume to the lack of backup or real evidence being attached to some statements. In some cases, such statements were simply misleading, or outright wrong. This isn't to question the honesty of those making such statements of course. >Let me be quite blunt: where the lies at? I don't remember exact emails, but let's call them simple misstatements. Not the result of dishonesty. >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. I don't see the relevancy? I think everyone knows the RFC was a collaboration among a number of intelligent experienced people. What is relevant is that the collaboration itself was not accessible by many of us - including me with my 0 Karma ;). Nobody else got the benefit of your discussions, which inevitably means we needed to rehash everything, challenge your assumptions, question your approach, and above all else request actual proof of the RFCs worth. It's the "proof" part holding up several of us. We can rationalise things all day, but without some form of proof it's not possible to make an informed decision - and therefore we will not make that decision yet. My experience so far is like watching a big blank wall. You talk to the wall, but you're left with the impression the wall doesn't really want to talk back. Finally you realise its responses were just echos from something that happened earlier but got a bit muddled while in transit, and go find something more interesting to watch - like mud. > 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. Arnaud is not naive and I welcome the idea of opening up RFCs for comment. However, the RFC has been carefully examined, considered and found wanting. Not wanting in all areas incidentally - but in one or two very specific places where many of us, myself and Matthew included, have requested additional backup. I think that most of the RFC is in fact not disputed very much? I'm quite capable of being rational and careful, thanks. Unfortunately being rational means we're cursed with an inability to make decisions based solely on iffy opinions and conjecture. Obviously since I was not part of the original discussion and debate which led to the RFC, I am unable to share this perspective from the lofty heights. How does it look up there? Is it true that Speed Freaks have fluffy white wings? ;) I'm kidding, of course. >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 We're aware of the methods - but the devil's in the details where we're not convinced. No amount of emails will change that until the RFC is updated as requested, and some amount of evidence/solutions produced for the remaining contentious points. Pure opinion is just not all that convincing right now, regardless of how well respected it may be. > 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). It sounds, and always has, like a completely unnecessary complication which many developers would rectify with a build tool like Phing or Ant if warranted. If such folk can't use a build tool, it's not my problem, so why should I cater to them? Why would a speed freak *not* want to muck around with a build tool? And why should a minority need be used as a sledgehammer to justify anything? To finish off here. You posted an RFC. You got comments. The RFC process worked. Problem, is that it worked too well! Lots of people questioned, poked, disagreed, challenged, agreed, raised concerns, used four-letter words etc. The problem is that many of these were not addressed, or were answered with outdated information, or weren't explained properly, or lacked any specific acknowledgment of disadvantages etc. All of which quickly got very confusing, frustrating, and pointless. Which is why I started the email with "The RFC needs updating, in my humble opinion, before this discussion can go anywhere". Because even this response is likely completely pointless since it contributes nothing new to the debate except as an urging to get the RFC updated. Best regards, Paddy Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Greg Beaver <greg@chiaraquartet.net> To: Matthew Weier O'Phinney <mweierophinney@gmail.com> Cc: PEAR developer mailinglist <pear-dev@lists.php.net> Sent: Saturday, July 21, 2007 2:39:33 AM Subject: Re: [PEAR-DEV] 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 -- 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