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

.. snip snip...

I am using PEAR_Error. Where is the description of its location? OK, that's a straw man because PEAR2 won't allow that :). Let's try this: <?php require_once 'MDB2.php'; $mdb2 = MDB2::connect('mysqli://user:pass@localhost/database'); ?> Actually it should say..

Fatal Error can no find "MDB2/Driver/mysqli.php" on line XX of MDB2/Driver.php using include path XXXXXXXXX Which is pretty obvious to fix.....

- Performance improvements, are negligible compared to that of a real life application.

based on what evidence exactly? How do you define "real life application?" An app that does database activity on every request? A real life application uses database requests, image manipulation etc. and many other places that are slow, and can be sped up. - as it has been explained many times, anyone concerned with performance will have to focus on those issues first. and chances are solving those will in turn reduce the number of included files, to the point where using autoload / preloading will result in very minimal improvements (or may even be detrimental). Discussing require_once issues and performance is a red-herring and really should not factor into any discussions of this.

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. If someone want's to try this out, and see all the long term maintenance problems they will end up with, let them, but please dont force it on everyone..

Because I am concerned with maintainability. Having the same code without modification makes it far easier to collaborate and remotely debug a problem that a user experiences. It also cuts down on the number of possible vectors for things to go wrong. ...snip snip..

what you offered is not 99.99% use cases, it's very much edge cases that may benefit from another arrangement. Edge cases should be solved as edge cases, not by re-designing the standards to suit them as if they are the major concern. If autoloading works so well, and is so simple, then having the installer just add // infront of require_once / include etc. on demand should this problem perfectly well. and not concern anyone. - If users require the allfiles.php feature, they can post a bug request with the suggested allfiles.php and let the package maintainer add it. This is not major automatic code refactoring, it just comments out a few lines of code on installation, on demand. for anyone who considers it a necessity, while leaving the original to work in the most simple easy to use way. function stripIncludes($source,$target) {

    |$source = file_get_contents($file);

||$tokens = token_get_all($source); $ret = ""; $inreq = false; ||foreach ($tokens as $token) {

||    if (is_string($token)) {
       // simple 1-character token
       $ret = $token;

} list($id,$text) = $token; |||

|    switch($id) {
      case T_REQUIRE_ONCE:
||       case T_REQUIRE:
||       case T_INCLUDE_ONCE:
||       case T_REQUIRE:
||          $inreq = true;|
|          $ret .= "\\" . $id;
||          continue;||           case ";":
         $ret .= $text;
         $inreq = false;
         continue;
||      case T_WHITESPACE:
          $ret .= $text;
         if ($inreq && strpos("\n", $text) > -1) {
            $ret .= "\\";
||          }
||          continue;
     default;
         $ret .= $text;

      }

} file_write_contents($target, $ret); } Solved = you get your flexibility, no-one is forced to use autoload unless they want to...... |||

These are my top 5, and as you can see, 3 of the 5 result directly from problems with relative path require_once. Is there something left off of that list that concerns you more?

1) package renaming - can be solved perfectly well with include_path mods 2) class splitting - not exactly a common problem... how many packages could this really affect < 10 ? - not really a huge require_once issue.. 3) multiple local PEAR repositories - can be solved perfectly well with include_path mods 4) deprecated packages disappearing or packages breaking BC - not really a require_once issue.. 5) using PEAR_Error - a historical issue.. I thought we wanted to get rid of the PEAR.php dependancy, not add a new one for PEAR_Autoload...??? Regards Alan

Greg