Re: Why change require_once? A brief explanation of motives

From: 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:
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);
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 ;)
So 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.
For the application side of things this may be different, but these rules are intended for the libraries not the applications
- 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


« previous php.pear.dev (#47593) next »