Re: Why change require_once? A brief explanation of motives

Hi, Lukas Kahwe Smith wrote:

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?

All packages in PEAR will be able to work with a single __autoload() implementation. So I do not see the issue.

OK, how will the usage examples and unit tests access this single __autoload() implementation?

Usage examples will expect the user to have defined this, just as we expect the include path setting to be setup today. Unit tests always require some sort of setup or runner script. This script can handle this part. Ideally one would be able to run the tests using autoload or allfiles, just to check if its works both ways.

Translation: neither usage examples, nor unit tests will work out of the box as they do now. And that, ladies and gentlemen, is also presented as a FUCKING HUGE IMPROVEMENT over current situation.

I do not see the issue with unit tests really. For usage examples it also requires installing the packages and setting up the include path. Again I acknowledge that any change will create some pains, but I do not see them as so gigantic.

There is, to put it mildly, a subtle difference between setting an include_path *once* when installing PEAR and mangling usage examples and unit tests on each package installation to make them work. And if you don't see an issue with unit tests then you probably do something wrong with them. Those for HTML_QuickForm2 run out of the box by just executing AllTests.php with php-cli.