Re: Why change require_once? A brief explanation of motives

Hi, Lukas Kahwe Smith wrote:

Well, except for the the fact that AllTests.php won't know where to find those classes, nothing.

You can test them by setting up your include path like always and using __autoload() or by using allfiles.php. Both can be written out once in your AllTests.php and never be touched again.

Oookay, so to run usage examples and unit tests one will still have to set up include_path. Thus everything said before about getting rid of that horrible chore is complete and utter bullshit. Case dismissed, I suppose?

No, alternatively you can setup your allfiles to use the proper relative/absolute path. Or you can setup your include_path. Surprise, all the options of this new proposal are available for people just as always.

Yes, that's exactly what I said, the users will have two options: 1) Either set up an include_path (no improvement over current situation) 2) Or change the examples / unit tests to load the allfiles.php from some absolute path (degradation of current situation)

But yeah, I do not really follow the include_path is hard for developers argument. I do know for a fact that some people run into include_path setting issue with their hosters, but then again I do not follow pear-general in quite some time. Maybe hosters have gotten smarter these days.

As I already said several times, the most common problem with include_path is the following: require_once '/path/to/pear/dir/DB.php'; $db = DB::connect('...'); $db->query('...'); and the person gets an error message stating that class DB_Error doesn't have a method named 'query' (duh!). Actual error message from include_once is silenced by @ operator. Well, if that person has some clue (or, more probably) is using a better tutorial then he adds error handling: $db = DB::connect('...'); if (PEAR::isError($db)) {

    die($db->getMessage());

} ...and gets an extremely fucking helpful error message of "Not found". The helpful error message *is* present, BTW, but should be output by getUserInfo(). But by that time the person in question turns to forums for help and I can't honestly say I blame him... This is *the* most common problem in setting include_path I continue seeing up to this day. But I daresay the problem is not in include_path, but in overall design of DB class. Oh, and your MDB2 does *exactly the same* by silencing the error in include_once and providing the PEAR_Error with unhelpful "Not found" message.

Alexey, this is getting quite boring, but I guess for you your mind is already made up, so you can just make your attacks and hope that "reasonable doubt" will be enough to stop this proposal. I guess you have stopped trying to expose real issues in the proposals and are now just trying to control public opinion.

I think that I've already exposed a more than real issue concerning this proposal in current thread. There are essentially 3 issues that need debunking in the proposal 1) We can get really huge speed improvements with APC 2) include_path is hard (and we can cleanly get rid of it) 3) __autoload() provides some benefits over manual including This thread, I think, got good care of argument 2). I think I'll need to run the benchmarks for 1) myself, since sponsors of the proposal are somewhat reluctant to run them. One has to wonder why... Oh, there was also the idea of unzip-and-go, but I think most people already understand that shifting the handling of dependencies from PEAR installer to clueless user is not that good an idea.