I've been working on the Cgiapp roadmap, and particularly on the plugin
architecture. I'd been operating under the assumption that I'd have to make
a PHP5-specific release (Cgiapp2) to allow this feature. However, it turns
out I'm wrong.
PHP has had overload functionality
since PHP4, and it has been in the standard build since 4.3.0. It turns out
that the only things I had to do differently to get plugins working in PHP4
(which work via the __call() magic overloading method) were to turn on
overloading for the function (via the overload() function, if available),
and to look for a global $CGIAPP_PLUGINS variable (rather than a class
static).
In doing so, I started evaluating the need for Cgiapp2.
It turns out I can do a large amount of what I'd planned for my Cgiapp2
roadmap in PHP4... which largely eliminates the need for Cgiapp2. However,
there are a few things which I can do more gracefully or better using PHP5
techniques -- such as testing for errors in the run mode, and overloading.
My decision is to create a separate class, Cgiapp5, which inherits from
Cgiapp and overrides methods as necessary. Currently, it unsets the
$CGIAPP_PLUGINS variable (as unnecessary), overrides the run() method (to
use exception handling instead of PHP's error handling), and overrides the
__call() method (to use the class static property instead of the global
variable). The unit tests so far show both versions as working and
compatible.
What I like about this pattern of development is that I can add some
powerful features now for PHP4 users -- who will be, for some time, I'm
certain, the largest base of users, until PHP5 gains momentum. But,
simultaneously, I can work with the more dynamic developments of PHP5
without sacrificing backwards compatability.
The downside is that there's little incentive for developers to write for
Cgiapp5 instead of Cgiapp -- and that's the future. However, at this point,
I want to aim for more developers than fewer.
Leave a comment and let me know what direction Cgiapp should take.
