Re: Why change require_once? A brief explanation of motives

Hi, Lukas Kahwe Smith wrote:

Alexey, I think you fail to understand that its not a black and white world. Its not about "the RFC sucks" or if you "believe" me or Greg. Its about finding a solution. Labeling things "idiocy" or whatever serves no purpose to this list. It might give you personal gratification.

Lukas, I think you fail to understand that people requiring changes have to provide the arguments, not those who wish to keep the status quo. People who are proposing the changes in question made a spectacularly bad job of presenting their arguments, since the RFC in question was published with no reasoning whatsoever. Is that the way PEAR is going to work now with "constitutions", "presidents" and "groups" above and unwashed masses below? 1) Where are the official benchmarks using the current version of APC (3.0.14) with all the optimizations on? Maybe we don't need to change anything after all? 2) If we are going to work around the deficiencies of third-party apps (APC, phar, whatever) then where do we draw a line? 3) The arguments that the proposed changes make life easier for users do not hold water. They just shift the support issues from e.g. setting the include_path to writing a proper __autoload() and / or manually loading dependencies. Most of the include_path support problems, BTW, happen due to driver loading (DB, MDB2) which currently returns PEAR_Error in case of missing files. This won't be an issue in E_STRICT packages throwing the Exceptions.

Now please explain how I am expected to run unit tests and usage examples without mangling them.

oops .. wanted to reply to this statement as well. could you elaborate about the problem you see?

The usage examples and unit tests need to load the package classes, you know, as well as dependencies. How are they going to find them?