Strings & Ints

This could apply to many things, but today it shall apply to… PHP.

I know, I know, I’m not the first one to rant about this, and I most certainly won’t be the last.

PHP is pretty much the only language I know deeply, and I’ve been working with it for ages. About 6-7 years I think, I’m never sure. It’s an excellent tool for building websites, but it has a dark side. And this side is very dark indeed; it’s called simplicity. PHP is so simple every idiot with a keyboard can slap his hand onto it and find a functional piece of code.

And here is where I like to make a rather important distinction between functional and working. A functional page does the job, but doesn’t necessarily do it properly. A working page on the other hand does the job, does it properly, and tries to do it as efficiently as possible.

You can probably guess where I’m going with this: in PHP, the difference between a functional and a working page is humongous. The smallest child can hack something together and call it his homepage, but not a lot of people actually know the intricacies and best practices that can make PHP a rather nice and powerful language.

This is why PHP needs developers with experience and a will to do the right thing, to optimise away and to see the errors in their ways. There are saddeningly little of these people. In fact, off the top of my head, the ones like this I can count on one hand. The rest more often than not say “but it works!”. But it doesn’t.

Of course, the same can be said for many other languages, including CSS: easy to cock about in, but hard to master.

You shouldn’t think that this is the only problem though; there are many others. And the problem just keeps on growing and growing. There have been a great many bad design decisions in PHP; register_globals, safe_mode, magic_quotes_gpc, short tags, just to name a few.

And now they’re doing more! Sure, they’re removing the previous design cockups, but they’re adding new ones. New ones that could be worse than ever, and with a reasoning even someone on LSD wouldn’t even be able to follow. If you’re been following the evolution of PHP lately, you’ll probably know what I’m going at: the new namespace separator. This is in my eyes one of the biggest atrocities they could’ve done to a decent language.

I mean, seriously, a backslash? That’s about on par with a smiley face (note: also suggested in that article). I see it going horribly wrong on so many levels it wants to make me cry (a namespace called ‘n’ called inside a double quote string anyone?).

Ever since they’ve been talking about namespaces in PHP, I’ve had my mind set on a decent way to do it: namespace inclusion. Sure, it wouldn’t be as pretty as in some other languages, but atleast it wouldn’t break backwards compatibility. I’ll set out my original idea to you.

Basically, it’d use the commonly ignored comment character #. Right now, # is a character used for single-line comments, just like //. I’ve perhaps come across one script that uses it, and I’ve seen my share of scripts. So no harm done if it gets a different meaning I’d say.

A meaning used in the form of:

<php
#using mynamespace

myFunction(); // It's really mynamespace::myFunction();
?>

And you could take that even further, using the #using directive as a way to signal to the interpreter “this namespace will be called upon, reserve it”.

So then it could be used in the way of:

<php
#using mynamespace

mynamespace::myFunction();
anothernamespace::aFunction(); // Would throw an error

class mynamespace { } // Would also throw an error
?>

This way the interpreter could reserve the name of that namespace and throw an error if any class tries to declare itself as that namespace.

I know, perhaps not the prettiest of ways, but it’s work, and we’d be able to keep the :: operator.

Or, you know, they could just make a namespace a static class and allow the nesting of classes. Problem (somewhat) solved!