Re: Why change require_once? A brief explanation of motives

Simon Ruderich wrote:

As many have already said the problem of setting up an include_path is not really existent. It's one line of code with no work behind it. And if someone can't handle then it is very easy to help him. I think easier then with __autoload() or allfiles.php.

I agree its not easier to teach someone to use __autoload() than it is to setup the include_path. Some people do have trouble setting the include path because their hoster is particularity stupid and disables ini_set and set_include_path(). However it is easier to teach them to use allfiles.php, but all of this isn't even the point for me. I think the added flexibility is good.

2) provide an autoload mechanism (PEAR2_Autoload)

Will there be such a class or not? Some say it and others say that there will be no such class.

Like I said, I think it should.

I'm against such a class because it requires on more file to load which we want to prevent. And it makes it slower and more complex then the current solution (require_once 'package.php').

Its optional.

To ensure this file is always present it should be generated by the packager (or installer). This would shift the work away from the developer and also away from the user.

I agree, though it should be possible for the package developer to hand tweak it.

But the problem with dependencies is still there. If I have 3 packages and the first depends on the others I have to read the code (or documentation) to find them and include all allfiles.php by hand (and there are more complex dependencies situations). All this has to be done by the user which I think is overcomplicated.

To me the allfiles.php is a documentation that should be hand tweaked by speed freaks. regards, Lukas