Re: Why change require_once? A brief explanation of motives

On 7/18/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:

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.

More coding, but it's not *that* terrible.

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

This is a little simplistic. What about singletons or registries, where you may be instantiating via a construct like: $foo == Foo::getInstance(); If you use the strategy you're suggesting, you're going to get a fatal error of 'method does not exist', which is going to further obscure the real situation (class does not exist, because file cannot be found). <snip>

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

I'm agreeing with you here. I think that allfiles.php was very poorly grouped with the call to remove require_once, and many have latched onto the idea that *every* file in a component would be loaded every time -- which would not be the case if an autoloader is present. <snip>

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

Going back to the example of the singleton above, that's not entirely true. You'd likely need to search for both 'new' and '::'... and '::' is going to be returning false positives once namespaces are released in PHP 6. Better would be the idea of listing dependencies in the class files, and I think that this would be a requirement for acceptance of any stable component.

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.

Interesting idea. I know with ATK, they have similar logging setup with their class loader, and this can be tremendously useful in debugging.

2) include_path is a config thing, while __autoload is a run time thing Auto prepend does not seem like an equally good solution

*gah* don't mention auto_prepend again, please! :-)

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

The only comment I want to make here is that you potentially add more logic, and thus more CPU cycles, with an autoloader than with a straight require_once. However, if particular classes are being loaded many times in a single application, you could also potentially save cycles (extra logic performed once, versus many require_once's of the same class file). -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/