When do you think we will see some movement regarding these issues. They are big problems with the way that ZF loads classes. It's almost impossible to develop classes where the ZF is going to load them e.g. _rowClass in Zend_Db_Table, even if I can get the code working first time I don't see any kind of strict warning etc.
So I have to start making modifications to ZF to remove the shutup operators everywhere I find a Zend_Loader::loadClass(). Is there anything I can do to help? I'm guessing there won't be any movment on this untill 1.5.2 is out the door. Thanks -- /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 > > > > > > > >
