ZF-2533: Zend internally doesn't use user-defined class loader

Description

Zend own internally doesn't use my own class loader.

I set this:


MyZendLoader::registerAutoload('MyZendLoader');

And now for example in Zend_Db_Table_Row_Abstract is used this:


Zend_Loader::loadClass($tableClass);

But this static method is hardcoded and doesn't use my class loader, but table class it's my own class and I need use own class loader for it.

I found simple workarounfd, but it's necessary modify Zend_loader class and I don't like it.


    public static function loadClass($class, $dirs = null)
    {
        if (class_exists($class, false) || interface_exists($class, false)) {
            return;
        }
        
        if (spl_autoload_functions()!==false) {
          spl_autoload_call($class);
          if (class_exists($class, false) || interface_exists($class, false))  return;
        } 

I only add


        if (spl_autoload_functions()!==false) {
          spl_autoload_call($class);
          if (class_exists($class, false) || interface_exists($class, false))  return;
        } 

If is defined autoload function, Zend_Loader::loadClass() use it instead of default implementation.

Comments

Resetting priority and assigning for review.

As of 1.5.1 the issue remains unresolved. This is my patch proposal. It will add an optional argument to Zend_Loader::loadClass() to specify whether to use autoload. *_Loader should call the method specifying false as third argument, while calls to Zend_Loader::loadClass() from Zend_Db component now works.

This is a pretty major change, and has wide ranging implications -- performance, class resolution, etc. While I can see the benefits, we cannot make a change of this scope until we are ready for a major revision (2.0).

I'm using the simple non-optional patch by Tomáš Procházka since march 2008 and it works pretty well. My setup is mixed: some classes follow ZF naming convention and some don't. The patch, together with my own class loader, makes any difference transparent.

As for the "wide ranging implications" I've seen none.

Assigning this to Matthew, as he oversees cross-cutting issues like this. I'd like to see a simple one-line comment that says with no uncertainty what we'll be doing- either wait for 2.0 or consider for 1.x.

Resolved in trunk and 1.8 release branch