2008-01-28

On Namespaces

Way back when I was an itty bitty boy, I started learning PHP. PHP is a great tool for being able to do a variety of things with a web server that you can't otherwise do without learning the nuances of CGI programming. PHP is great for doing stupid things like parsing a user's session information and spitting it back at them along with the time and date, and it can create both really nice and really horrific database interfaces. I've seen, used, and created both.

Probably the worst thing about PHP is the same thing that makes it so approachable by neophytes. It's the 21st century's web-savvy version of BASIC, so beginners love it. Problem is, PHP makes doing hard things easy and stupid things even easier. PHP lacks a good way to manage something that, much later in my career than I should admit to learning, I found out were called "namespaces".

What's the big deal? I wondered. PHP lacks namespaces, and that makes doing everything prettydarned easy if you ask me. And it does. But from a design standpoint, PHP now makes me want to put a gun in my mouth. (These days, most things do.)

So if I want to use PHP to generate some e-mail, I can do that. There are a slew of mail_* commands that I can rely on. Ditto database commands, HTTP commands, string manipulation, and so on. They are all, effectively, built into the language. You don't have to declare your desire to use them as you do in other languages. There's no PHP equivalent for "#include <string.h>" or "use Net::SMTP;" or "require 'Date'". All these things are just there, ready for the taking.

So. What's the big deal? Well, these commands aren't magic. The php binary has to support them somehow, so you need to either statically compile them into to your /usr/bin/php program when you build it yourself, or you have to build a bunch of shared libraries that /usr/bin/php will be able to find, talk to, and offload the pieces-parts that it doesn't natively understand. This means that every PHP binary and every PHP installation is, somehow, different. There are different libraries built, there are parts that aren't in libraries but rather put into the core binary itself, and so on, and so on, and so on.

Structurally, it's a mess. Logistically, it's a mess. For programmers, it's great because you never have to worry about where your system calls are. But at the same time, there is the constant threat of namespace collision: the dreaded result of two chefs labeling totally different ingredients in the exact same way. PHP gets around this by just creatively naming every single function: instead of just calling connect() on the object or type of the thing to which you wish to connect, you have your choice of db2_connect(), pgsql_connect(), mysql_connect(), oci_connect(), and so on. This can become absurb when you get to the part in your API where you need to define mysql_connect_persistent_with_callback_dob() or something wordy like that.

So PHP is great to teethe upon because it helps the beginner to very quickly start making cool things that work. It's awful because it doesn't really enforce strict coding standards that, without learning them, will seriously hamper you as a developer. When I look at PHP now, I see its programming environment as a joke. It's a cool tool that was clearly developed by amateurs (or the criminally insane), and with no real appreciation for doing the right thing instead of doing the easy thing. It's a joke, but it seems no one's laughing.

No comments: