PSR-0 style autoload for D7

Here is a simple (D6) module that does work both standalone and in combination with the existing autoload module.

Classes should be named
class [module name]_CamelCase[whatever] {}
They are to be placed in files within
[module dir]/lib/...

Yes, maybe it would be more psr-0-like to call them ".php" instead of ".inc". Undecided about that.

For instance, my own classes typically look like this:

// In [nodeaspect module dir]/lib/PageInfoCache.inc
class nodeaspect_PageInfoCache {..}

// In [nodeaspect module dir]/lib/InjectedAPI/hookNodeaspectPage.inc
class nodeaspect_InjectedAPI_hookNodeaspectPage {..}

// In [dqx_adminmenu module dir]/lib/InjectedAPI/structureAlter.inc
class dqx_adminmenu_InjectedAPI_structureAlter {..}

The module name MUST be all-lowercase, with underscore allowed.
The module name MUST be followed by underscore + a capital letter.
The capitalization of the rest does not matter.
Any further underscores will be turned into directory separators.

Having the last fragment lower camel case is a stupid habit of mine. Irrelevant for the autoloader.

---------

The autoloader has two parts:
1) Active discovery / directory scanning.
2) Passive lookup.

By default, it just does the passive lookups. This will happen for any module, no matter what the info file says.

If the original (D6) autoload module is enabled, it will scan the lib folder of those modules that have a autoload hint in their info file. The result is added to the registry, thus using it as a cache. I suppose this has performance benefits - but that depends on the implementation of the registry.

The module maintainer can now choose if the lib directory should be actively scanned, or just passively looked up.

I should mention that I have not tested this thing in combination with the existing autoload module :)
Probably needs some module weight adjustment, to decide which autoloader should have priority.

More accurate title :)

The big question is, should I start a separate module, or rather have this included in the existing autoload module?
And if I go for a separate module, what should the name be? xautoload is a bit meaningless.
I refuse doing the files[] game in any of my own code. It just feels plain stupid.

Is this ever going to be considered for autoload module?
I would hate to fork / make yet another module.

See http://drupal.org/sandbox/donquixote/1420754
I mark this as "needs review" to get some attention... please let me know if you want to see a patch.

X Autoload now has a public D7 release.

I am already using xautoload in a number of modules (basically every new module I write, or old module that I revamp), and I am quite happy about it.

This said, none of these modules use PSR-0, they all use a pseudo PEAR standard.
E.g.,
class my_module_Foo_Bar -> "$my_module_dir/lib/Foo/Bar.php"

PSR-0 is implemented, but I don't want to make my D7 modules require PHP 5.3.
Still, this is a huge improvement over the autoload registry, imo. And it will be quite straightforward to port this structure to PSR-0.

If you want to help, you could add some unit tests.
Also some benchmarks to compare with symfony loader would be nice. In theory, uncached xautoload should be faster than symfony, because it does not loop through all namespaces for every non-cached lookup.

The "pseudo" was from an argument that is now history.
Both xautoload and classloader support straight PSR-0.

classloader is the clean and minimal backport, xautoload is more custom-ish with additional support for other stuff and claims to scale better with many namespaces (needs benchmark).

The question in #11 still holds.

Another argument to not make this a D7 of autoload would be to avoid any false assumption that autoload-6.x and classloader-7.x would have anything in common. Because they don't.

Fair point.
Changing issue title.