What are the list of requirements for Zend_Loader::loadClass() to work as expected. With the patch you've provided in the incubator does Zend_Loader::autoload() work as expected.
-- /James On Fri, May 9, 2008 at 1:23 PM, Darby Felton <[EMAIL PROTECTED]> wrote: > James Dempster wrote: > >> 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. >> > > Not necessarily. The solution in the incubator is only for ZF-2923. More > would likely need to be done to solve the multiple problems related to use > of Zend_Loader. > > Best regards, > Darby > > >> -- >> /James >> >> On Wed, May 7, 2008 at 9:01 PM, James Dempster <[EMAIL PROTECTED]<mailto: >> [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] >> <mailto:[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 >> >> >> >>
