List of alternative autoloader concepts/implementations

[dnaber-de]

Just to collect some that are worth an investigation:

• Symfony ClassLoader component
• Drupal autoloader components https://www.drupal.org/project/autoload, https://www.drupal.org/project/registry_autoload
• level-2/axel

[Chrico]

• Aura
• Composer

[bueltge]

Typo3 Repo, Documentation

[rmccue]

The autoloader we use at Human Made fits with the WP file naming scheme (WP_Some_Class -> class-wp-some-class.php) and supports namespaces.

[rmccue]

This is also being used with some small changes for the new W.org plugin directory.

[tfrommen]

@rmccue what we have in mind here, basically can achieve the same as your autoloader. However, we split the different types of loading a class (e.g., PSR-4 namespaces, or class-wp-*.php, or wp-*.class.php) into individual rules. The difference is that this way you can easily extend the autoloader, and don't have to register an adjacent one, not taking advantage of what's there already.

Great comment on Trac, BTW. :)

[mikeschinkel]

WPLib: Optimized for fastest loading and more importantly for minimized number of lines required during XDEBUG-ging.

https://github.com/wplib/wplib/blob/master/wplib.php#L319

I would love to see WordPress core first use an optimized classmap autoloader, and then if that does not find the file then its okay to start looking using the separation of concerns approach.

[franz-josef-kaiser]

@mikeschinkel You might be using XDebug the wrong way. Anyway, please take a look at the internals of the other autoloaders before continuing the marketing for your package. That would help to actually compare something.

[mikeschinkel]

@franz-josef-kaiser

Anyway, please take a look at the internals of the other autoloaders before continuing the marketing for your package.

You are assuming I have not. I definitely looked at other autoloaders in preparation for my own as I did not like how they worked.

You might be using XDebug the wrong way.

Care to elaborate?

[franz-josef-kaiser]

@mikeschinkel

Care to elaborate?

Sounds like you are not able to skip steps.

I definitely looked at other autoloaders in preparation for my own as I did not like how they worked.

Well, you did. But what does anyone else have to compare yours with others? There are no stats to show it's more performant, there is no broken out autoloader setup that is comparable with the industry standard loaders.

[mikeschinkel]

@franz-josef-kaiser

Sounds like you are not able to skip steps.

Sorry, I don't follow.

There are no stats to show it's more performant, there is no broken out autoloader setup that is comparable with the industry standard loaders.

Reading the title of this issue I only saw "List" and not "In-depth Bechmarks and Analysis" in the title which is why I commented; I did not know the latter were a requirement. I had time for the former but due to client demands currently do not have the time for the latter.

That said, here is code:

function _autoload( $class ) {  
    if ( isset( self::$_classmap[ $class ] ) ) {
        require self::$_classmap[ $class ] 
    } 
}

It is not comparable to "industry standard loaders", but then the question is, does it really need to be? You don't need to employ a full warship when a small powerboat is sufficient.

[dnaber-de]

The actual goal of this project was to provide an implementation to overcome drawbacks of existing solutions. Everything that does not follow straight the SOLID principles is legacy and there are dozens of existing implementations.

[mikeschinkel]

@dnaber-de In general I am enthused by your proposed solution. I do however think that being 100% SOLID is an optimization which may be in conflict with optimizing for performance, and a minimization of lines of code that need to be run in the autoloader during debugging.

So I would like to see more like 85% of the solution being 100% SOLID and with a non-SOLID optimization for the most optimized use-case which IMO should be a class map.

[dnaber-de]

I do however think that being 100% SOLID is an optimization which may be in conflict with optimizing for performance, and a minimization of lines of code that need to be run in the autoloader during debugging.

What makes you think that? How does the number of lines of code affect the script execution?

[mikeschinkel]

How does the number of lines of code affect the script execution?

Number of lines of code is an optimization for debugging, not necessarily script execution. If I attempt to single step into this line because I want to debug the constructor I have no idea if it will trigger the autoloader or not.

$foo = new Foo();

Ideally I would like to see the most common autoloader use case be minimized to running no more than 2 or 4 lines of code for these unfortunate debugging cases.

As for performance, I have learned by hard lessons on having code reviews done by companies who are running on cloud-based file systems that excessive use of file_exists() can have serious performance implications. A classmap bypasses any need to inspect the disk in order to be able to load the class.

[dnaber-de]

Use composer, PSR-4 and a proper IDE, than you won't have to debug your autoloader anymore.

[mikeschinkel]

@dnaber-de You misunderstand my point. I do not want to have to debug my autoloader, but the best IDE on the market which I use does not allow me to single step into a constructor without first debugging into the autoloader if it is called.

Which does bring up a great idea for a feature request in PhpStorm; a preference to bypass debugging autoloaders.

[mikeschinkel]

@dnaber-de BTW, PSR-4 requires the use of file_exists() if I am not mistaken, does it not (unless only one autoloader is possible to be in use)?

Also PSR-4 autoloaders do not map very well to WordPress plugin, mu-plugins and themes.

[dnaber-de]

Finally we're completely off-topic. However, I don't want to leave this without reply.

PSR-4 is a concept about how to map FQCN to a file – there's nothing said about how to implement it. (Btw: That was one reason I separated file locating from file including.)

You misunderstand my point. I do not want to have to debug my autoloader, but the best IDE on the market which I use does not allow me to single step into a constructor without first debugging into the autoloader if it is called.

That is what unit tests are for. Testing components in isolation. Maybe you use constructors in a way they are not meant for. I can't imagine any situation where you would have to debug a constructor and how an autoloader would interfere with it. Maybe you want to explain a concrete example in an article – I would be really interested in. If you send me a link, I'll reference it here for the sake of completeness. Until that, this issue is locked.