Posted by david on 26 June 2014 at 5:29 pm
I try to build toward speed first. It's not always the sexiest approach, but sometimes smaller is better. In this case size doesn't matter. One of the features of Clay's module system is the ability to plug in submodules that act like on-demand APIs. The best way to use them is to structure a module's base class toward use cases instead of direct need. For instance, the Plugins module has a Get() method that pulls in a submodule class object. Now an entire class of methods are only loaded when I need to use Get (). It also has methods for implementing a hook or installing a plugin from an application. Without submodules over a dozen methods would all be in a single class, most of which only get used a fraction of the time. Why load all of those methods when they likely wont be used? SubModules make this happen on-demand, with very little base module code. Today I expanded SubModules capability by adding a new class that supports object classes as SubModules as well. Previously only static classes could be used. See the library/Clay/Module folder to view the code. The API class supports static classes (to stay inline with other Clay functionality) and the SubModule class supports objects. The Setup module employs similiar functionality, but without using SubModules (currently). Clay may have a few bottlenecks here or there, but the base is by far the fastest framework I've seen or used and that's sexy.
Log in to comment