Re: clarification on the performance of require_once andAPC

Alan Knowles wrote: > I think alot of the arguments against the require_once changes have been > hashed out many times before, in far too many emails, and yet this > proposal appears to have ignored the crux of most of them. It is still > being forced on with "Requirement - No exceptions to this rule". > > - The Performance improvement would only realistically affect ~ 1% of > users who are that concerned about performance (who should be capable of > working around the issues). Most of us are more concerned with > maintaining large codebases over 5+ year timespans... - and not having > to dig through code to understand it 1 year after writing it... > - All the examples shown are considerably more confusing from a > debugging, coding perspective than the existing status quo. > > The examples and thinking behind the proposal appears to be targeted at > large packages, with > 10 files, with no consideration for smaller > packages, which are far more common. - throwing exceptions for missing > dependencies is not what exceptions are supposed to be used for! > > In it's current state all this "not allowed" seems not to have > considered any of the rather lengthy emails that have been published on > the subject. The Priorities on PEAR2 based on this appear > > 1. Speed, Speed, Speed > 999. Readable, Mainatinable, easy to fix code. Come on Alan, do you really expect this kind of rhetoric to lead to anything resembling productive discourse? > where as PEAR has always prided its > 1. Readable, Mainatinable, easy to fix code. > 3. Code that can be easily modified to improve speed. The proposal seeks to improve readability and maintainability through a number of the sections. For example: 1) mandating the 1-file = 1-class rule, which was not a rule in PEAR. 2) mandating an even clearer directory structure for code in CVS 3) setting up a clearer path to move to stability (requiring docs and unit tests) In addition, and perhaps you missed this, but the example you chose of throwing exceptions for missing dependencies is one of the original proposal's segments that is likely to be thrown out. You probably also missed the email I sent after returning that stated we are trying to work out the problems in the RFC before unnecessarily revising it. You may have also missed the note at the bottom of the RFC detailing potential problems, which is a good place to add other concerns until consensus is reached: Possible Problems * Removing require_once makes it harder to document missing files * The current data_dir system is easy to mis-code and must be revised. A proposal is on pear-dev for this exact purpose. * How should dependencies be handled in allfiles.php? Should the packaging tool optionally automatically bundle current dependency versions for unzip-and-go users? * The current requirement on PEAR2::Exception introduces an automatic dependency for all packages. Perhaps PEAR2::Exception should be a simple bundled class or perhaps all Exception classes should inherit Exception? As you can see, the require_once concern is at the top of the list. Your incendiary claim "and yet this proposal appears to have ignored the crux of most of them" is patently false, bordering on flame bait. The RFC is a work in progress, please drop the aggressive tone. Greg