Re: [Coding Standards] Loading all files at once

Paul M Jones wrote:

On Jul 9, 2007, at 4:44 PM, Joshua Eichorn wrote:

Philippe Jausions wrote:

I also find include_path quite useful. How to address lazy-loaded user self-patched PEAR packages, if not with include_path? (note the dirname(__FILE__)) Also, how would package inter-dependency be handled with allfiles.php file(s)? -Philippe

I find include_path useful too, but having to set is also a very common complaint about pear.

There are lots of common complaints about PEAR ;-) some of them warranted and some of them not. I think this falls in the "not warranted" category, myself. It seems a lot more important when you want to bundle a portion of PEAR inside you wordpress plugin to make your graphs just work. There are lots of other cases including environments where you don't have permission to set the include_path.

Anyhow if you use constants as part of the allfiles.php you can create a setup where you can still use include paths as needed. Something like: |if (!defined('PEAR2_PATH')) { define('PEAR2_PATH', dirname(__FILE__).'/'); } require PEAR2_PATH . 'HTTP/Request.php'; Then if you want to use include path you just set PEAR2_PATH to an empty string.

This might be the seed of a useful compromise; instead of requiring allfiles, we might state that require/include use the PEAR2_PATH prefix in all cases.

With the current setup its hard to do any sort of custom include scheme you have to edit every file.

What kind of custom include scheme are we talking about? In what common situations is a custom include scheme necessary? Maybe you want to concat all the code into file so you get maximal caching benefit. Or because you want to be able to easily make a phar.

Or you want to replace class x with a replacement for one place, and class y from an older version of pear. I can think of lots of cases like this i've run into. Its not super common but when it happens the flexibility is very nice.

With allfiles.php the includes are outside of the code so its very easy to do custom schemes, you just make a file that does what you need. Its also worth noting that outside of driver based packages the majority of the code is used no matter what you do. Inter-dependency could be handled by one allfiles.php including another one

It is just these sorts of small complexities that bother me with allfiles; how is this simpler or better than including as-needed? To reiterate an earlier point: With packages like MDB2 and Text_Wiki, a *very* large number of files have to be loaded here. I don't think it's necessary or prudent to do so in those cases. As such, I think *requiring* an allfiles solution is unwise, although an optional "recipe" or "practice" for it is fine with me. (As an aside, a developer emailed me offlist to suggest that if allfiles really is that important, perhaps it can be handled by the packaging process.) You either have the includes in the file or you don't. We can easily generate allfiles.php files, and even subsets based on the subpackage you want to use, but horking hundreds of files to remove the require_once is a much bigger deal.

But that doesn't mean there isn't another solution. It just means your includes are going to look a little messy. -josh