Re: require_once vs. no require_once - please read, criticalinformation

Alan Knowles wrote: >> 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. This is an opinion Alan, and is based on dismissing any evidence I present to the contrary. Not sure what else I can say beyond "talk to Gopal if you don't believe me." >>> 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 ... again, in your opinion. You're telling me that problems I have encountered in a significant amount of my coding experience are edge cases? > 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...... This last statement shows supreme ignorance of the problem, but I can forgive you - you obviously have never actually tried to do the thing you are talking about. For a real life example of trying to mung require_once, take a look at the PHP_Archive-based scripts that do exactly the kind of thing you're suggesting. They're complex, really difficult to debug, and prone to dramatic failure when run indiscriminately on role="php" files. >> 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 ??? include_path mods won't do anything to help here, it's in the code itself. You have to update the require statements to load new code, otherwise you're either not loading it, or loading old code. include_path has nothing to do with that. The point was that in the old system this: <?php require_once 'Old/ClassName.php'; $a = new Old_ClassName; ?> requires a double replace to: <?php require_once 'Old/ClassName2.php'; $a = new Old_ClassName2; ?> Again, this is a long-term issue that affects packages that break BC, something that has affected many more than 10 packages (check for packages ending in "2" for example). > 2) class splitting - not exactly a common problem... how many > packages could this really affect < 10 ? - not really a huge > require_once issue.. Certainly, in a moribund listless repository this isn't a problem. For an example of this kind of continuous development, take a look at any of the faddish ones (Zend, Cake, Symfony, etc.). I've done class splitting in every package I've ever developed, and I maintain at least 10 packages myself, are you claiming that I am the only person doing this? > 3) multiple local PEAR repositories - can be solved perfectly well > with include_path mods Again, the point is that the include_path mods are necessary - with the proposed solution, they are obsolete. Additionally, have you ever tried to debug an improper include_path? It can take hours to figure out what is causing the problem, and sometimes it isn't possible to fix without major re-tooling. For instance, one time I had to install a separate PEAR repository with 15 packages just to fix a problem with 1 class. This problem simply doesn't exist with the proposal. > 4) deprecated packages disappearing or packages breaking BC - not > really a require_once issue.. ...as I said in the email itself. > 5) using PEAR_Error - a historical issue.. ...as I said in the email itself. The list of maintenance issues was a complete list of long-term maintenance issues I experience almost every day (#5 popped up today in my work on pearweb, so unless 5 hours ago is historical...) > I thought we wanted to get rid of the PEAR.php dependancy, not add a > new one for PEAR_Autoload...??? There is no proposed dependency on PEAR2_Autoload, you may want to read the proposal more carefully. In no location within role="php" code will PEAR2_Autoload ever be referenced (except within the PEAR2_Autoload package itself, of course). role="doc" examples is another story. I asked for examples of long-term maintenance problems you encounter regularly that are different from the ones I provided, are there any? Thanks, Greg