Re: Why change require_once? A brief explanation of motives
| From: | Alan Knowles | Date: | Wed, 18 Jul 2007 07:32:54 +0000 |
| Subject: | Re: Why change require_once? A brief explanation of motives | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-47593@lists.php.net to get a copy of this message | ||
Lukas Kahwe Smith wrote:
Alan Knowles wrote:Well, I do not think that this really qualifies as a good solution. It's perfectly clear what's happening and why.. looks perfectly good to me ;)How am I supposed to lazy load an the Exception implementation by just relying on require_once?depending on how you use Exceptions (control flow or in exceptional situations) require_once 'MyPackage/Exception.php; throw new MyPackage_Exception_FileNotFound($thefile);
For the application side of things this may be different, but these rules are intended for the libraries not the applicationsSo far the only justification that is currently not been explored for this change is "enables more flexibility" - Could you explain how it would enable that? and why that flexibility would be useful and commonly used. I can not see any amazing flexibility, only more problems.I think I just posted some examples of how this is useful, short summary plus a few extra from the top of my head: - being able to gracefully handle missing classes How exactly should you handle missing classes in your library?! - It's a pretty fatal situation, you would have to have screwed up the installation pretty badly. .... We've been doing kludges before in various factory methods to try and prevent error messages in this situation, but in the end, PHP's file not found in include path is the easiest for anyone to understand.
- being able to shorten the include path in case for some reason you end up having a lot of entries in your include path Is this a common situation, or even a recommended situation. It only affects developers during development. at most you are likely to have 3 elements to the include path in a live applications "." , pear directory , custom library directory. - Again its not a huge benefit.
- getting rid of stat calls (I know we need new benchmarks on the relevance of this one) As we have discussed this is irrelevant. if you care about stat calls, you would not be loading libraries with many files with code that is not used.
- wanting to add some logging/debugging at class load time you want logging/debugging of your library loading. there are many ways to do this.. using ticks and checking the length of get_included_path should work perfectly well.Regards Alan
regards, Lukas