Re: Why change require_once? A brief explanation of motives

Alan Knowles wrote:

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 ;)

I was not referring to the fact that its not clear, but to the fact that you would have to end up combining a require_once call in all places where you lazy load a class implementation.

- 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

You can create the class on the fly, throw an Exception when the class is instantiated and catch it some where. You can provide a nice happy message to the user and contact who ever is supposed to fix this. I do not see this as generally needed though, but if you have a certain level of dynamic's going on. Like a CMS with plugins and you pull out data defining what class to load from a database etc. Obviously you could take other steps to determine if the class will be available before you make an instance, but this way its conveniently centralized.

- 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.

Generally I do not think this is a common situation. Most people get by with 2 or maybe 3 paths. Assuming its only relevant for development is wrong however. If you are glueing together various things, it might not be so feasible to copy everything into one directory.

- 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.

Its not irrelevant. The allfiles.php proposal might have blurred the idea. This is an option for speed freaks, that will most likely hand tweak this as much as possible.

- 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.

could you elaborate? Anyways, I do not think that the majority (I will not attempt to make any guesses as to the exact numbers) of the current users will necessarily leverage any of these proposals. I think we are getting rid of an issue some people that are not using PEAR had. I think we are also opening up a lot of possibilities that people will appreciate if they discover that they have a need for this. I think at this point I am tired of having to repeatedly show the potential benefits of this proposal. What I think is much more worthwhile would be to focus on exactly what we are loosing if we move to this proposal. 1) IDE's and humans can easily grep for require_once For IDE's I do not know the impact. For humans I think you can just as well grep for "new". You can also hook debugging mechanisms into __autoload(), which would be a run time thing versus being able to grep just the code on disc. 2) include_path is a config thing, while __autoload is a run time thing Auto prepend does not seem like an equally good solution 3) overhead from calling __autoload() I tend to think that the inherit lazy loading nature of __autoload() will offset this issue for people not using a byte code cache @Alexey: If you reply, please stay of the FUD regards, Lukas