*Backtrace thread: [fw-general] Opcode cache [was: Shared server load times]
*
**
Since you are going to revamp the code, how about something *generic*?
Function to *conditionally *include files:
static function includeFiles( $files )
{
if ( function_exists( '__autoload' ))
return; // Files get loaded automatically/lazily
//
foreach ( $files as $key => &$file )
{
require_once( $file );
}
}
Example usage for RewriteRouter.php at its top:
Zend::includeFiles( array
(
'Zend/Controller/Router/Interface.php',
'Zend/Controller/Request/Abstract.php',
'Zend/Controller/Request/Http.php',
'Zend/Controller/Router/Route.php',
'Zend/Controller/Router/Exception'
);
...
...
Hope it satisfies those who use __autoload() and those who do not.
Regards,
On 12/21/06, Bill Karwin <[EMAIL PROTECTED]> wrote:
I appreciate everyone's input on this discussion. I'd like to reach
closure on what we do with Zend::exception(). I will summarize my
viewpoint on this issue, and then give my proposed resolution:
- Calling Zend::exception() is nonstandard PHP usage. This is an
education issue for developers using the Zend Framework.
- The stack trace generated from an exception is also nonstandard,
holding the location of the call to Zend::exception() is the second
line, instead of the first. So knowing how to read a stack trace from
Zend Framework is also an education issue for developers.
- This affects usage of IDE tools, which may provide clickable stack
trace output. Developers will be confused that clicking on the stack
trace always opens the source of Zend::exception().
- Zend::exception() sets the file and line of the exception
instantiation, not the place where it's thrown. This means the file and
line is always set to Zend.php line 227. Accounting for this requires
additional code to set the file and line to the place that calls
Zend::exception, but that still wouldn't fix the stack trace.
- Lazy-loading exceptions can be achieved in a traditional manner by
putting require_once() inside the code-block that creates an exception.
- Lazy-loading may be unnecessary in an environment that uses a bytecode
cache. I assume that any application that prioritizes performance
enough to be affected by the overhead of loading exception classes
should be running a bytecode cache.
So I propose the following resolution:
- Remove instances of Zend::exception() throughout the ZF tree,
replacing them with traditional "throw new" usage.
- Mark the Zend::exception() function as deprecated in 0.7.0.
- Remove the Zend::exception() function from the Zend class in 0.8.0.
- Continue to implement each exception in a separate file. Not all
exception classes are no-op extensions to Zend_Exception; some do
contain custom methods.
- Individual component authors may implement lazy-loading by putting the
require_once() into each code block before instantiating an exception
class. But I don't think this should be required; it's fine to
require_once() exception classes once per file, at the top of the PHP
file, and rely on bytecode caching for performance improvement.
I grepped, and found we currently have 358 instances of using
Zend::exception(), and 652 instances of traditional usage ("throw new
Foo_Exception;") in the tree. So we are using Zend::exception() in only
one-third of the cases of throwing an exception.
Comments? Tomatoes?
Regards,
Bill Karwin
PS: I'm volunteering to make the edits to replace usage of
Zend::exception() with traditional exception usage.
