Introducing the concept of Extendable Object Faces (API)

Preliminary Warning: "If you're afraid of classes and objects in PHP, run away now." - jpetso. Update: For simplicity the API has been changed so that all faces are incorporated, thus modules have to care about naming collisions theirself. Also in the meantime file inclusions support has been added. While figuring out a object oriented design for the rules engine I recognized the need for a possibility to allow modules extend objects in various places. Thus I developed a generic concept which does just that: Allowing modules to extend objects. I called the concept "Extendable Object Faces", which basically implements the Facade pattern in a modular way. So let's have a closer look at that. A module that wants to extend an object may only do so on top of a defined interface, preventing uncontrolled growing objects. Thus one can write some code, define an interface for it and attach it to potential any extendable object out there. Then other modules have an easy way to test whether some object has a functionality in place by checking for the availability of a certain interface. To use that functionality the caller has to use the right "Face" of the object - corresponding to a certain interface. This approach using different "Object Faces" make sure there can't be conflicting method names, so modules don't need to prefix their methods with the module's name which would result in ugly and not readable code. I've already implemented an initial version of the Extendable Object Faces API. As of now you can:

• Extend an object by providing an Extender Class
• Extend an object simply by some functions, each implementing a method
• Override any dynamically added method by providing functions or an Extender Class

So apart from "allowing modules to extend an object", this also allows one to:

• Easily lazy load huge parts of an objects implementation, invisible for the caller.
• Allow modules to dynamically alter an implementation by using overriding.

Hence such an Extended Object can also serve as a clean abstraction for module provided callbacks! Enough talk, let's show how it works: This code provides the class for the Extendable Object and already defines an interface, which modules may implement. So let's extend it with an Extender Class. object->name; } } ?> That's it. Now you can use the face! name = 'test'; $element->extendByClass(array('FacesTestInterface'), 'FacesTestExtender'); // Now use it. print $element->face('FacesTestInterface')->isWorking('Name:'); // This prints "Name:test". ?> As you see, one has to use the face to be able to use the added method - so potential name collisions are avoided. However the Extendable Class can define so called incorporated faces, which are built in the Extendable Object as soon as a module provides an implementation: So you can use it that way, once extended: isWorking('Name:'); ?> You can find more examples in the simpletests I've written. Also checkout the benchmarks I've run. So what's missing? Basically the implementation is complete and working fine. Though feedback and suggestions are very welcome! However currently the code doesn't deal with including code where the implementation can reside (lazy loading), though for drupal 7 that is already solved by the code registry (just add one call to drupal_function_exists()). For drupal 6 I think about adding the possibility to specify include files per added interface.

Dreaming...

If we would have an object oriented "Data API" in drupal core, this could serve as a way to let modules extend those objects. So instead of writing node-centric code code could would be written in a generic way - attachable to potentially each of those data objects (users, comments, terms). Having such generic code would allow us to finally end the "Everything should be a node" debate. Apart from that this would help us to easily lazy load big chunks of code, just exploiting the code registry!