What makes an excellent PHP Extension?

Posted by santosj on November 12, 2006

Why do I preach extension’s holiness before I even try them? I evaluate them based on how likely I’m going to use and abuse them in the near future. How much work the extension will save me while working on my own projects, as well as other packages. The final criteria is how easily it will be picked up and accepted by novices or if I was learning the language, would I love this feature?

As a programmer who has worked with a lot of different languages, I can tell you from experience why I feel the way I do. I’m sure other programmers who go way way back can say the same thing. The love towards a language must be more than the frustration of completing tasks, whether the complexity is simple or difficult.

If the language doesn’t supply tools, then you’re going to have xyz from just about every other competent or not so competent programmer brave enough to try their hand at providing them for you. Which is bad. Given two separate packages, one might include one library that implements the feature their way and another a different way. Having to constantly relearn libraries that provide the same feature is pointless.

ext/Filter

Whether or not it is “complete” does not really matter, there will be time to add in features later. Either Pierre or another competent C coder who wishes for that filter support.

It is a step up from where PHP was recently. With no default Filter extension, coders were left with primitive filtering devices. Trying getting a novice to fall in love with Regex is difficult. As someone who has fought that battle, it is not one that is won easily.

Given that PHP developers has a history of incompetence (myself included) with security, it is finally nice to have something to start the battle of restoring PHP reputation. Does the Filter extension solve every Filter problem? No, but it is a start. No longer will the excuse, “AHHHHHHH!” apply.

If I had a dollar for each iteration of writing an email regex, well, I just don’t want to have to do it anymore. I would like to see the Zend Framework Input Filter code for the email RFC. Looking at that RFC, one might lose their insanity thinking about what would have to go into the regex. Whoever successfully does that is a God and praise be his or her name.

I will start using it and I will probably start submitting suggestions, if not by that time I relearned C/C++ to add it myself (which I’ll probably not do anyway). Yeah, I mean, there could probably be improvements, but could I have done better? Hell no, so I shut my mouth.

Standard PHP Library

I compare it mostly to STL or Standard Template Library, which if you worked with C++ before 2001, you’ll probably had issues based on which punk ass compiler you had the (mis)fortune of using. I remember a friend had to use a local version of random.h because the compiler didn’t install it by default.

What is also bad is that I’m not seeing a lot of code that uses the observer model using the SPL Observer classes. SPL is there for a reason and it is quite simple to learn, much similar to the delight of a C++ novice using STL (you don’t have to know how it works, but only that it does).

The difference between STL and SPL is that PHP had already a lot of features that had to be added in STL for C++. It is a shame that SPL is wasted on what is mostly Iterators when it could be so much more. There are quite a few gems for those who use them.

PDO

Yeah, I have bitched before, but it was mostly my arrogance. My posts before I used it, were positive. The reason? I have looked over ADODB, ADODB Lite, phpBB own DB abstraction, and developed my own DB abstraction. I can say that finally having the foundation of a DB access abstraction that everyone can use and enjoy is a good thing indeed.

Possibly Related Posts:


Projects

Comments are closed.