Larry Garfield wrote: > See, I'm working on a different approach for Drupal. We're actually scanning > our own code base and building up an index of all classes (and functions!) in > the system, saving that to the database, and then the autoload implementation > just polls the database for the file that needs to be loaded and loads it. > The class itself can literally live almost anywhere. There's some more code > on top of that for caching and routing optimization and such, but that's the > basic idea and it's actually looking really sweet. :-) It should be landing > in HEAD very soon.
This is actually very similar to another approach I'm taking too with my projects. I run "make" on the modules which takes several actions: * Extracts strings for i18n and merge in to the .po files etc. * Build up a list of what interfaces classes implement and/or what classes they extend (because those base classes may implement an interface(s) too!). This parsed list of implementations is stored with the module (nothing is enumerated to a DB at this stage). In my code, as a module is loaded this list is also loaded and put into an application wide structure. This approach makes it incredibly simple to write Observer based design patterns (e.g. you can ask the system for all classes that implement the "ArticleSubmitted" interface - then instantiate or statically call as appropriate). Modules can be turned off/disabled/uninstalled of course and that means their implementation lists are not loaded and they will not be called when an observable event occurs. It's all very nice IMO and I certainly like working with it. Col -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
