On 4/27/12 2:51 PM, Steve Clay wrote:

This is operational in my "autoloading" branch, with mostly testing to come, but since
it's built on Symfony components I have a good feeling.
https://github.com/mrclay/Elgg-leaf/compare/Elgg:1.8...mrclay:autoloa...

In fact it's better than planned: All the classes directories and anything passed to
elgg_register_classes() is deep-scanned for any PHP files, using the tokenizer to
correctly recognize interfaces, namespaces, and traits in a backwards compatible way (if
you run PHP 5.4 you can use traits in your plugins immediately). The resulting class map
is cached between requests.

Notes:

* There was a chicken-egg problem in that you can't load a full classmap cache until you
know the dataroot... which you need classes to find. So until the classmap can be loaded,
the autoloader just uses PSR-0/PEAR style loading out of Elgg's classes dir, which
eliminates the need to make a mostly unneeded temporary map over the whole directory.

* Once the dataroot is known, the system pulls in the cached class map and a list of
directories that have been formerly scanned (to help it avoid re-scans).

* I moved all the autoloading facilities to a core Autoloader subpackage in
lib/autoloader.php.

* There are 3 small-ish new classes loaded and a 4th only when scans are needed. This
design separates the concerns of the class map, the autoloader, and managing persistence
of the system. The classes use DI strictly and should be easy to unit test or use in any
other framework; all the Elgg-specific wiring is in elgglib.php and a tiny bit in ElggPlugin.

* $CONFIG->classes has been replaced by $CONFIG->autoload_manager, which holds a reference
to the ElggAutoloadManager instance. That class wraps a ElggClassLoader, which wraps an
ElggClassMap. Only the class loader is exposed in the public API, but if that's unwise for
1.8 I can just rename it and mark it @private.

* The Symfony2 licenses (BSD) were pulled into the PHPDoc in the Elgg versions.

Steve
--
http://www.mrclay.org/