Re: __autoload() enhancement

On Sun, 3 Apr 2005, Andi Gutmans wrote: > I don't think the right solution though is to leave the not-optimal > solution in the engine, and create a solution outside the engine. I think > we should find a way to tune the engine so that it works well. Zeev's > suggestion keeps BC. If there are concerns as far as chaining order are > concerned, I personally don't have a problem supplying an API function > where functions can be added programmatically. > We'd then get the best of both worlds and make it very accessible by everyone. FWIW, I don't think maintaining BC is super important here. I don't believe lots of people are using __autoload() currently, and it should be pretty trivial to migrate to whatever solution we end up with. I would prefer we concentrate on getting the __autoload() behavior that we think is right. If we can do both, then that's a win-win, but we shouldn't let BC get in the way here for the two reasons I outlined above. Also, from a timing perspective, if we are modifying __autoload(), I would suggest that PHP 5.1 would be the correct place to introduce it. Finally, on the point of "does order matter?" I think order does matter. I may want to pull classes from a general framework (such as PEAR) and also from my own personal set of classes. I don't want to accidently include a PEAR class that has the same name as my own class. I believe Andrey's reference to include_path (or the PATH variable in your shell) is a good one. What if we said developers can't rely on the order of their path? The feature would be far less useful because of clashes. -adam -- adam@trachtenberg.com | http://www.trachtenberg.com author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today!