Re: Error supression on calls to loadClass across ZF obscuring parse errors

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 <letssurf@... <mailto:letssurf@...>> 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 <darby@...

   <mailto:darby@...>> 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