Autoload via .info files

The main reason is that the logic to detect classes inside a file is non-trivial regexing. Non-trivial regexing scares me. :-) It's one of the reasons I never went there. (The other being that this module started as just a proof of concept and the hook was easier.)

That said, were we go to that route I would actually prefer to just go all the way. Scan all info files, look for a files array, drop the info hook, etc. That would definitely warrant a 2.x branch of the module.

I suppose I'm undecided here if it would be sufficiently stable.

Thinking about it, actually, we may still need the hook for 3rd party libraries. I'm actually working on a module right now that uses a 3rd party library via the libraries module. The files[] array wouldn't account for that. See: http://engineeredweb.com/blog/10/5/3-tips-using-external-libraries-drupal

I'd like to get feedback from other module maintainers that depend on autoload. This introduces a lot of new moving parts, and given how late we are in the Drupal 6 lifecycle I am not yet convinced it's worth it.

Mike, can you scare up some dependent module maintainers so we can get input from them? :-)

@mikeryan There is a problem with your approach in #10. If you have to load 50 classes in 50 different files you add 50 sql queries. This is not so good for performance. From an autoloading performance perspective it's a definite slow down.

To avoid this in D7 there is caching. You can see the details in http://api.drupal.org/api/function/_registry_check_code/7.

I do like the idea of auto-detecting classes. But, the performance hit needs to be worked out first.

Would very much support this approach. I'm working on backporting the latest SimpleTests from D7 back to contrib and things would be much easier if we could have the modules define their .test files in the .info files and be included automatically.

Here's a revised (simpler) version that basically backports D7's registry to the autoload namespace, including all the same caching that D7 does. We still support the legacy hook_autoload_info() but only to pass that information into the registry scanner. Using this implementation people wanting to include classes from libraries can also implement hook_autoload_registry_files_alter().

I'm almost wondering if this should be split off into a backported namespace of 'registry' but I'd rather coordinate with the existing project first rather than duplicate.

Revised patch fixing some small bugs during the backport that I discovered while integrating this with the SimpleTest backport for D6 - which improves performance.

I'm lazy... so... I WANT!!!!!

So what say you Crell? +1 or -1? :)

1. Is the patch acceptable for the 1.x branch seeing as it completely supports the old hook?
2. If not, can we create 2.x branch for this code?
3. If not, :(. I guess we'll create a registry module for the backport, but I really don't want to fragment efforts, especially since lots of modules have gone through the effort of depending on automodal.

I talked to Dave just now, and here's the low-down:

- This is definitely 2.x material, as it's essentially a total gut rewrite of the entire module. The support for hook_autoload() is kind of an afterthought for backward compatibility.

- The registry in D7 has been mostly rewritten since I last worked on it, and it's doing all kinds of screwy things with variable parameter types. I neither comprehend the code anymore nor do I support that architecture, and am therefore not willing to support it.

- Fortunately, Dave is. :-) Dave Reid has been added as a co-maintainer on autoload and will be making a 2.x branch for this code shortly. Because, you know, Dave doesn't have enough modules already.

I'll let him close this issue when the time is right.

Hooray! Committed the backport to DRUPAL-6--2: http://drupal.org/cvs?commit=417548

Thanks for your help and input Crell!