I really can't see any slow down using the Loader from the incubator. I've created some small benchmarking scripts which shows to me it's just as fast (used the Zend_Loader::autoload() to benchmark).
Would this mean all the classes that are currently doing @Zend_Loader::loadClass($classname); would change to Zend_Loader:autoload($classname); ? Cause I notice that only Zend_Loader:autoload(); has the error handling in it. -- /James On Wed, May 7, 2008 at 9:01 PM, James Dempster <[EMAIL PROTECTED]> wrote: > Thank you for you detailed reply. > > I will certainly be trying this new class and hopefully get back to you > tomorrow. > > Thanks > -- > /James > > > On Wed, May 7, 2008 at 7:18 PM, Darby Felton <[EMAIL PROTECTED]> wrote: > >> Hi James, >> >> The overall problem with Zend_Loader is fairly nuanced and has different >> ramifications for people using it in various situations. This problem is >> definitely on our radar, and we are thinking about a reasonable solution >> that meets the original Zend Framework goal of "extreme simplicity" while >> enabling reasonable performance expectations. >> >> Basically there are two competing issues: >> >> 1) Zend_Loader::loadClass() and loadFile() do not check to see if a file >> is readable before using include_once upon it. This causes a warning to be >> issued when the file does not exist, but the extra time for checking whether >> the file is readable is not required using this approach. This is annoying, >> for example, to people using Zend_Loader with multiple autoloaders because >> of the extra PHP warning noise. >> >> 2) Error suppression of the above (i.e., with "@") causes any resulting >> error to be hidden. This is annoying, for example, when loading a user class >> that contains a parse error because the error is harder to find than if the >> error had not been suppressed. >> >> In the meantime, there is a modified version of Zend_Loader I made in the >> incubator if you want to try it out. I'd be particularly interested in >> performance benchmarks, if someone would have time to do such a thing, but I >> haven't heard about any such results to date. >> >> Of course, guidance and contributions from community members like you to >> help solve these issues are most appreciated! :) >> >> Best regards, >> Darby >> >> >> James Dempster wrote: >> >>> Hi All, >>> >>> I've wasted so much time creating row classes and not finding out about a >>> parse errors all because line 119 of Zend_Db_Table_Rowset_Abstract and it's >>> shut up operator. >>> >>> See http://framework.zend.com/issues/browse/ZF-2724 >>> >>> My application would just silently die without any errors in my php.log >>> or in the output. Very very frustrating. >>> >>> Can some one explain to me why they are there, why there is such a >>> reliance on Zend_Loader. Why can't it just try to create the object and have >>> any class auto loads deal with it, including user auto loads. Using >>> Zend_Loader in this way put a reliance on Zend_Loader and with the @ sign >>> break my app without me knowing where the problem occurs. >>> >>> What can be done to solve this? I've tried removing the @ sign and all >>> seems to work fine. The same problem exists in other classes. >>> >>> -- >>> /James >>> >> >
