Re: require_once vs. no require_once - please read, critical information

[snip] > Removing require_once does *not* make it harder to develop using > include_path as we are all used to and fond of, in fact it is slightly > easier. Compare: > > old way: > <?php > require_once 'MDB2.php'; > require_once 'HTML/QuickForm.php'; > require_once 'My/Package.php'; > require_once 'Another/Package.php'; > ?> > > new way: > <?php > require 'PEAR2/Autoload.php'; > ?> > I DO care about performance in my 'real life' applications, and unless you conditionally include ALL lib files at every instance in your main glue code (which is nearly impossible, and a waste of time unless you use an autoloader) - even [php handled] cached output can take a performance hit because of all this: require_once require_once require_once ... etc etc Your explanation, tests and examples make this decision obvious to me Greg... thanks for providing the details. <Alan Knowles> "I have no idea why you can't create a package, PEAR2_StripRequires which removes all the requires and let's you use autoload or allfiles." This looks like it would cause more maintenance problems for an application which utilized installable packages. If I strip the requires (read: modify the package's code) for a package I use within my custom application - this will require more work to upgrade that package if a new release comes out. I come from a perspective where I utilize PEAR packages within an application which is distributable, and also applications which utilize a single pear library on a server. If you want high performance in your distributed application which utilizes a lib you'll have to modify the source and distribute that dependency along with your application - which means 1. you can't take advantage of libraries which may exist already on the system 2. If a security issue comes up with that dependency --- For the end user to upgrade that lib they'll have to figure out how that package is added in to the application, or wait for a new release with the bundled (modified) library, OR the end user could have multiple versions of a library on his server one easily upgradeable, one not easily upgradeable. 3. It's harder for the application maintainer to update that packaged lib in the distributed code because patching from the latest version can also be problematic... you'll have to interactively patch to see what changes are made, or accept the full patch and then run the strip requires again. Seems to make more sense to use the same code in all places so they're easily upgradeable for the end user - and offer the flexibility so that the application can utilize existing libraries on the system. Greg, these changes sound like a good direction to go, thanks for all of your patience. -- -Brett Bieber http:saltybeagle.com aim:ianswerq