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
