Error supression on calls to loadClass across ZF obscuring parse errors

[JDempster]

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

[pakmannen]

I second this. I haven't used Zend_Db before but recently started to look into it, and had this happen to me.

Also, would be great if something was done about the autoloader throwing warnings when a class isn't found. Very annoying in a developer environment when you are using more than one autoloader.

Think these issues will be fixed in time for 1.5.2?

/Jens Ljungblad

JDempster 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

[JDempster]

I certainly hope that they're fixed in time for 1.5.2 if it's not on the agenda to be fixed by then, what can I do to help?

On Wed, May 7, 2008 at 6:07 PM, pakmannen <jens.ljungblad@...> wrote:

I second this. I haven't used Zend_Db before but recently started to look
into it, and had this happen to me.

Also, would be great if something was done about the autoloader throwing
warnings when a class isn't found. Very annoying in a developer environment
when you are using more than one autoloader.

Think these issues will be fixed in time for 1.5.2?

/Jens Ljungblad

JDempster 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
>
>

--
View this message in context: http://www.nabble.com/Error-supression-on-calls-to-loadClass-across-ZF-obscuring-parse-errors-tp17103401p17109864.html
Sent from the Zend Framework mailing list archive at Nabble.com.

[Darby Felton]

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

[JDempster]

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@...> 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

[JDempster]

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 <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@...> 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

[Darby Felton]

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
>
>
>

[JDempster]

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

[JDempster]

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

[Matthew Weier O'Phinney-3]

-- James Dempster <letssurf@...> wrote
(on Monday, 12 May 2008, 02:29 PM +0100):

> 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.

Correct. And if you're that anxious, you can help by providing a patch.
:-)

Truly, though, this is a complex issue, for the reasons Darby has
outlined previously. It is a priority, however; we just need to make
sure we have a fully BC solution that addresess all of the concerns, and
this will take a bit more time. Patience, please... unless you can
provide a tested patch. :-)

> On Fri, May 9, 2008 at 1:23 PM, Darby Felton <darby@...> 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 <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
>
>
>
>
>

--
Matthew Weier O'Phinney
Software Architect       | matthew@...
Zend - The PHP Company   | http://www.zend.com/

[JDempster]

A patch? :¬) lol I wish I could provide the solution or help more.

I will continue to submit patches where I can. As you say this is a complex issue which I don't fully understand all of the problems.
I'll be patient.

;¬D
--
/James

On Mon, May 12, 2008 at 2:52 PM, Matthew Weier O'Phinney <matthew@...> wrote:

-- James Dempster <letssurf@...> wrote
(on Monday, 12 May 2008, 02:29 PM +0100):

> 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.

Correct. And if you're that anxious, you can help by providing a patch.
:-)

Truly, though, this is a complex issue, for the reasons Darby has
outlined previously. It is a priority, however; we just need to make
sure we have a fully BC solution that addresess all of the concerns, and
this will take a bit more time. Patience, please... unless you can
provide a tested patch. :-)

> On Fri, May 9, 2008 at 1:23 PM, Darby Felton <darby@...> 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 <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
>
>
>
>
>

--
Matthew Weier O'Phinney
Software Architect       | matthew@...
Zend - The PHP Company   | http://www.zend.com/