Allow me to preface this with some context. I <3 PHP. It’s probably my favorite language for a variety of reasons, but the number one reason being I’m pretty expert at it. But I’m not above recognizing that the majority of PHP programmers are generally idiot script kiddies, and don’t know how to write code that is not terrible. In that way, all PHP programmers get a bad name, because, like in all other aspects of life, the morons far outnumber us geniuses. It’s our cross to bear.

Anyway, PHP is dead. Probably. Here’s why.

PHP is Stagnating

PHP 4 was released in May 2000. PHP 5 was released in July 2004. PHP 4.4 was released in July 2005. PHP 5.3 was released in June 2009.

These dates are not enumerated here to poke fun at the slow release cycle of PHP (I’ll get to the core team later). Rather, it’s to illustrate a point. Here are some numbers that I pulled from some random data dump from some non-English site that’s probably totally legit:

SELECT
	SUBSTRING(libelle, 1, 1) `php version`,
	SUM(nombre) `count`
FROM stats
WHERE libelle REGEXP '^[3-6](\\.\\d(\\.\\d)?)?$'
AND `date` LIKE '2008-10-06%'
GROUP BY SUBSTRING(libelle, 1, 1)

php version  count
-----------  -------
3               8096
4            2396211
5            1977067
6                 23

If it’s not abundantly clear to you unwashed masses what a “libelle” is, I’m pretty sure that’s “label” in some kind of European language. The dataset represents a census documenting what technologies people use to power their sites. Basically, this query is saying that in October of 2008, 2.3 million people used PHP 4 on their website and 1.9 million people used PHP 5 on their web site.

At that time, PHP 5 had been stable for 4 years, and PHP 4 had been stable for 8 years. Their usage in production is pretty much even. PHP 5 added a lot of features, such as, you know, object-oriented programming. And yet it takes ten years (and counting) for PEAR to get off their asses and convert their code to PHP 5.

For those who don’t know, PEAR is the PHP Extension Application Repository. It’s a packaging mechanism similar to yum or apt-get, as well as a repository for extensions to the PHP language written in PHP (as opposed to PECL, which are extensions to the PHP language written in C). It defined a coding standard, and generally did a lot of good for the PHP community, except that it’s written in freaking PHP 4, and the coding standard is embarrassingly terrible.

For example, they prefix member variables with underscores to indicate that it’s not public, since PHP 4 didn’t have the notion of member variable accessibility. PHP 4 also didn’t have the notion of static. You should see the way they implement the singleton pattern in PHP 4. It’s pretty hilarious.

PHP 4 also didn’t pass objects by reference. That means you manually had to insert ampersands everywhere to make sure that your objects wouldn’t be treated like a value type. And when I say everywhere, I mean everywhere. This is a very common occurrence in PHP 4:

$myReferenceType =& new AwesomeClass();

DEAR GOD YOU COULDN’T EVEN USE THE NEW KEYWORD WITHOUT EXPLICITLY DEFINING THE REFERENCE. WHY ARE PEOPLE STILL USING THIS VERSION OF PHP?

This is all a long way of saying that PHP 4 is hideously outdated, both in calendar time and technologically, and yet it remains very prominent. I die a little inside when I see someone using a host that’s rocking Apache 1.3 and PHP 4.3. It’s like seeing someone using the cgi-bin directory. Aren’t we past that yet? This isn’t 1997 anymore.

The same argument goes for PHP 5.3 as well. It added some sorely missing features, such as namespaces and true anonmyous functions, as well as a plethora of classes in the SPL, and yet no one is upgrading. It’s been a year, and people are still creating classes called Awesome_Controller_Abstract instead of using namespaces like a normal person. It’s heartbreaking.

This is what will cause PHP to always be slightly behind the curve technologically: its users’ snail’s pace upgrade rate. Eventually, its one strength, the extremely low barrier to entry, will be nullified as other languages figure out how to be more accessible to the masses.

The PHP Core team is separated from reality

So, I imagine this is a problem for a lot of languages, and I’m definitely making unfair blanket statements, but I want to bring it up for one very specific reason. Try to read the next sentence without laughing.

In PHP, the namespace separator is the backslash.

You laughed, didn’t you?

Allow me to give a bit of backstory without citing any sources.

There was fairly raging debate among the core developers on what to use for the namespace separator in the months before PHP 5.3 was released. You see, it wasn’t as simple as you might think, because PHP isn’t primarily an object-oriented language.

The original solution was to use the paamayim nekudotayim (scope resolution operator, but the Hebrew version is way cooler) as a namespace separator. But oh no! That caused problems in situations like this:

//bar.php
namespace Bar;

function foo() {}

//meanwhile, in baz.php
require_once bar.php;

class Bar {
  static function foo() {}
}

Bar::foo(); //which foo gets called? in the Bar namespace or in the Bar class?

So, the core team realized they had a problem. There were several solutions:

1. Only apply namespaces to OO code (classes, interfaces, etc.)
2. Change the namespace separator character to something unambiguous

Hindsight is always 20/20, but the second option there seems pretty retarded to me. It’s hard to find an unambiguous character in any language that has previous releases, because they’re all being used. What happens is you’ll end up choosing a character that’s hard to type (i.e. one you have to press shift for), or you’ll choose something that’s unambiguous technically (meaning not significantly used) but has ambiguous semantics (like, say, the escape character in every language besides T-SQL).

At one point, the core team actually created a matrix where each row was a different character (I think the triple colon was in the running at one point, which would probably be even more awesome when translated to Hebrew), and each column had funny stuff like “is hard to type” with a numeric value. The last column summed up the numeric values and the row with the highest number was the winner. It was all very democratic (THROUGH PURPLE MOUNTAIN MAJESTIES…).

The backslash won.

Well, kind of. Pretty much everybody who typed code for a living hated the backslash because, you know, IT’S THE BACKSLASH. Nobody wants to look at that.

But PHP is an open source project, which means most or all of them don’t get paid to work on it, so that means that the easiest solution will win. And in this case, the easiest solution was the one that was already done. One of the core developers got tired of the bickering and the matrices and the Hebrew and he spent a weekend implementing the backslash namespace separator and committed it to the branch. Then he wrote tests covering all possible cases, and created a patch against trunk.

He had everyone at “tests” and “patch”. And that’s how the backslash became the namespace separator for PHP.

This was all a a long way of saying their decision was made with their brains instead of their guts. If they used their guts, they would have realized that NOBODY GIVES A CRAP ABOUT NAMESPACES EXCEPT PEOPLE WHO DO OBJECT-ORIENTED CODE. Nobody cares if the 4000 lines of random functions in stuff.php is in a namespace. The only people who care about namespaces are those that experienced it in another language (like say, an object-oriented language) and would want to apply the same organizational structure to their PHP code. And those people are only writing classes and interfaces.

Ergo, they should have ignored the collision issues illustrated above, only applied namespaces to classes and interfaces, and rocked the PAAMAYIM NEKUDOTAYIM like it was going out of style. But since the PHP core team are experts in C, not PHP, they didn’t really realize this.

Instead, we are condemned to a life full of backslashes. I’ve already started a support group.

PHP 6 is a disaster area

I don’t have a lot to say about this, except that it seems like it’s an absolute disaster. The main thing going on in PHP 6 is unicode support.

yay.

I’m not totally sure why that’s so awesome, but it’s a lot of work, and it isn’t going well. Again I’m not going to cite any sources, but it’s been in the works for about two years to add unicode support to PHP, and I don’t think it’s very close to being done.

The problem seems to be that they can’t just add unicode support, because every extension would be incompatible. So they’re trying to retroactively add unicode support to everything at once, which is as terrible as it sounds. I could be making all this up, but it sounds similar to something I might have read once.

Basically, they’re attempting to add a feature that will be of minimal value, and it’s taking forever. Instead, they could be adding cool things, like some of these:

• C#-style properties
• Auto-boxing
• Traits
• Enumerations
• Function call chaining (oh god yes)
• Static classes

In Conclusion

PHP is dying. Probably. I hope I’m wrong, because I think PHP is a very expressive, convenient language. It has, by far, the best function library of any language. It also has, by far, the best documentation of any language, as well as a giant, open community around it. For those reasons, I hope it doesn’t die. But I’ve seen little evidence that it’s not going to march straight to hell.

Of course, you’re at the mercy of whatever kind of limping scrod they shove out their codehole, but hey, it’s free!

Quite often, their stuff sucks, or they don’t maintain it, or it doesn’t compile, or it doesn’t work, or it only works in certain environments, or whatever. But every so often, you find that one nugget of well-maintained and well-written rad that makes you love America! Or in this case, it makes you love the Netherlands.

I was following up on on this post and trying to compile the PECL translit extension on 64-bit Windows. Obviously, I was destined to fail. And fail I did. So then I emailed the author of the extension with a cry for help:

I was curious if the translit extension is available for Windows. I noticed there was no configuration file for it, so I attempted to hack together a config.w32 and build it but didn’t have much luck. Is it conceivable that this extension is buildable on Windows?

I’m trying to build it for PHP 5.3 on x64, which probably isn’t helping my chances…

Anyway, the documentation I found didn’t mention if it was even viable on PHP 5.3, so I could be barking up a dead tree. For the record, the error was pretty immediate and looked like this:

C:\code\php64\php-5.3.1\ext\translit\data\compact_underscores.c : fatal error C1083: Cannot open compiler generated file: ‘x64\Release_TS\ext\translit\data/compact_underscores.obj’: No such file or directory

Thanks,
Tommy

I didn’t really expect anything back for a while. I know he’s a busy guy, and there hadn’t really been any updates to this extension for a couple years, but I figured I’d give it a shot. In 3.5 hours, I had a reply that said, basically, “I’m not sure if it works on Windows, but you can pull the latest from SVN to make it build. I just built it on 64-bit Windows but I haven’t tested them.” And then he freaking attached the compiled DLLs. Both thread-safe and non-thread-safe versions. Seriously. Here’s proof:

That’s dedication to maintaining your project. Not only did he answer my question, but he went the extra mile of verifying that it was a solution himself.

Derick Rethans, you are rad. There needs to be more open source developers like you.

PS: I checked out the latest version of translit from the SVN repository he specified and rebuilt, and it totally worked.

I’m so sick of Lisp hackers. Functional programming is pretty awesome, but every single Lisp/Erlang/Haskell/Clojure/Emacs guy thinks Lisp is the greatest thing since list processing (what?).

So I implemented Reddit in (properly formatted) PHP in 97 lines. Granted it took a bit longer, but I had to remember how to use the low-level mysql_* functions. Oh, and I used MySQL. I don’t know what the Lisp people used for data persistence. Some of the lines were taken up by CSS and JavaScript, and making things look nice(r).

Reddit in 61 minutes of alone time with Notepad++

Source | Playground

I hate Lisp people.

var s = string.Format("My name is {1}, {0}", "Tommy", "Montgomery");
//s = "My name is Montgomery, Tommy"

var s = string.Format("My name is {{{0}}}", "Tommy");
//s = "My name is {Tommy}"

I needed that. Here it is, PHPified:

function format($format) {
	$args = func_get_args();
	$format = array_shift($args);

	preg_match_all('/(?=\{)\{(\d+)\}(?!\})/', $format, $matches, PREG_OFFSET_CAPTURE);
	$offset = 0;
	foreach ($matches[1] as $data) {
		$i = $data[0];
		$format = substr_replace($format, @$args[$i], $offset + $data[1] - 1, 2 + strlen($i));
		$offset += strlen(@$args[$i]) - 2 - strlen($i);
	}

	return $format;
}

There’s a lot going on in here that isn’t used very often in PHP. Here is a terse explanation of the not-so-obvious features:

• The PREG_OFFSET_CAPTURE constant tells the regex engine to capture the string index offset of each match.
• (?=\{) and (?!\}) in the regular expression are positive and negative lookarounds, respectively. The nice thing about that is they’re also zero-width matching, which means they won’t be returned as part of the match result. These are needed because to output a literal { in a C# string you precede it with another { (a little know fact about C#).
• substr_replace is an infrequently used, extremely useful function, that replaces a substring within a string, expanding to the given width.
• The $offset variable tracks the string length delta. Since we’re modifying the string, the offsets captured in the regex match becomes out of date.

Mmmmm… smells like win.

PHP 5.3 introduced closures. It’s already been pointed out that the Closure class in PHP is not necessarily a closure. Lexical scope is optional in PHP’s implementation, which is a little goofy looking:

//lambda ftw
$lambda = function ($x) {
  echo 'I am an anonymous function ftw.' . "\n" . $x;
};

//closure lol
$closure = function ($x) use ($lambda) {
  $lambda('Actually, I am an anonymous function lexically bound in a closure ' . $x '.');
}

$closure('lol');

//I am an anonymous function ftw.
//Actually, I am an anonymous function lexically bound in a closure lol.

It’s all very academic.

Object-Oriented Closures

Creating a closure inside a class is easy enough… until the desideratum is a closure around $this. It’s time for some JavaScript-style naming conventions!

class Foo {
  public function bar() {
    $closure = function() use ($this) {}; //syntax error: Cannot use $this as lexical variable
  }
}

This yields a syntax error in the form of Cannot use $this as lexical variable. That is truly misfortunate. Fortunately, we can reach into our bag of JavaScript tricks and do something ridiculous:

class Foo {
  public function bar() {
    $that = $this; //lulz
    $closure = function() use ($that) {
      $that->baz = "I was set by " . __FUNCTION__;
    }

    $closure();
    var_dump($this);
  }
}

$x = new Foo();
$x->bar();

/*
object(Foo)#1 (1) {
  ["baz"]=>
  string(22) "I was set by {closure}"
}
*/

True to PHP’s nature, it’s all magic and voodoo. (ab)Use with discretion.

A real world example

So, I was sitting there the other day, porting ASP.NET MVC to PHP, and I ran across this class:

internal sealed class ControllerDescriptorCache : ReaderWriterCache<Type, ControllerDescriptor> {

    public ControllerDescriptorCache() {
    }

    public ControllerDescriptor GetDescriptor(Type controllerType) {
        return FetchOrCreateItem(controllerType, () => new ReflectedControllerDescriptor(controllerType));
    }

}

Now, the significant part of this class actually takes part in the base class, ReaderWriterCache, which provides a thread-safe object cache. Basically. In this context, that’s really all it’s doing. The FetchOrCreateItem() method either retrieves an already-existing item in the cache, or creates it, stores it in the cache keyed to the specified type, and then returns it. Simple enough.

Now, thread safety is not a concern in PHP. Well, it’s of grave concern if you’re writing an extension, or working on PHP itself, but if you’re writing PHP code, you need not concern yourself with thread safety. The point is that this ReaderWriterCache is thoroughly useless in the context of PHP, so I needed to decide what to do with it. It turns out that I actually need it, but I already have a Collection class that does typesafe object storage, which is really all I need. The way it works is that it takes a Closure as a constructor parameter, and uses that for validation: if it returns true, the object can be stored in the collection.

//a collection of stdClasses. how useful.
$stdClassCollection = new \PhpMvc\Framework\Collection(function($value) {
  return $value instanceof stdClass;
});

Now, how to implement a generic object cache? Well, Collection is already generic (as generic as a dynamically typed language gets, anyway), so really we just need an implementation of FetchOrCreateItem() and we’re home free. But, since we’re awesome, and this post is all about closures, we want to use closures. Also, if you dig a little deeper into the MVC source, you’ll see the significance of the lambda expression in the second argument given to FetchOrCreateItem() (hint: look at line 15):

protected TValue FetchOrCreateItem(TKey key, Func<TValue> creator) {
    // first, see if the item already exists in the cache
    _rwLock.AcquireReaderLock(Timeout.Infinite);
    try {
        TValue existingEntry;
        if (_cache.TryGetValue(key, out existingEntry)) {
            return existingEntry;
        }
    }
    finally {
        _rwLock.ReleaseReaderLock();
    }

    // insert the new item into the cache
    TValue newEntry = creator(); //OH HAI! I CAN HAZ LAMDUH!
    _rwLock.AcquireWriterLock(Timeout.Infinite);
    try {
        TValue existingEntry;
        if (_cache.TryGetValue(key, out existingEntry)) {
            // another thread already inserted an item, so use that one
            return existingEntry;
        }

        _cache[key] = newEntry;
        return newEntry;
    }
    finally {
        _rwLock.ReleaseWriterLock();
    }
}

The reason for a lambda expression instead of just passing in the object instance is because it’s a cache: we don’t want a bunch of object instances floating around, so we’re waiting until the last possible moment to create it. Notice that first we check if the object exists in the cache before creating it; you can’t have that foreknowledge (well, you could, but lambda expressions are fun, and I’m assuming that’s the reason why this method is needlessly complicated).

So, let’s port it to PHP.

class ObjectCache extends Collection {

	private $creator;

	public function __construct(Closure $creator, Closure $validator = null) {
		parent::__construct($validator);
		$this->creator = $creator;
	}

	public function offsetGet($key) {
		if (!$this->offsetExists($key)) {
			$this[$key] = call_user_func($this->creator, $key);
		}

		return parent::offsetGet($key);
	}

}

There’s some serious magic going on here. I love it. First, recall that Collection implements the ArrayAccess interface, which means we can use array-style indexers on it. What happens behind the scenes when you do that is that it calls the underlying offset[Get|Set|Unset|Exists]() methods. So we override offsetGet() and either return the object if it already exists in the cache, or create it, store it, and then return it. Let’s see it in action:

$cache = new ObjectCache(
  function ($key) {
    return new \ReflectionClass($key); //when adding an object to the cache, this function creates that object
  },
  function ($value) {
    return $value instanceof \ReflectionClass; //only allow instances of ReflectionClass in our collection
  }
);
$stdclass = $cache['stdClass'];
var_dump($stdclass);
var_dump($stdclass === $cache['stdClass']);

/*
object(ReflectionClass)#4 (1) {
  ["name"]=>
  string(8) "stdClass"
}
bool(true)
*/

That triple equals, to those of you who forgot, means the object instances are identical, i.e. they refer to the same space in memory. Mostly what it means is that our object cache works.

Making the Object Cache Better

So, we can still set stuff in our object cache, since I didn’t override offsetSet(). Doing something like this will totally bypass the caching mechanism:

$cache['foo'] = new ReflectionClass('stdClass');

That’s not really very good. There are a couple ways to short circuit that:

1. Abuse the hell out of debug_backtrace() and fish the calling scope out of the stack frame (awesome)
2. Make offsetSet() throw an exception every time it’s called, and set the data another way

Well, it turns out that in my implementation #2 is not even possible, because the internal storage in Collection is a private variable not available to derived classes. What this means is that the only way to add an object to the collection is via offsetSet(). But there are ways around that, with a little refactoring. Since both #1 and #2 sound fun, let’s do both.

#1: Stack Frame Rape

public function offsetSet($key, $value) {
	//this method is only allowed to be called from within an offsetGet() in this ObjectCache instance
	$fail = true;
	$stackFrame = debug_backtrace(true);
	foreach ($stackFrame as $frame) {
		if (isset($frame['object']) && $frame['object'] === $this && $frame['function'] === 'offsetGet') {
			//called from $this->offsetGet(), that's okay
			$fail = false;
			break;
		}
	}

	if ($fail) {
		if (count($stackFrame) <= 1) {
			//called without scope
			$type = '{main}';
		} else {
			//the offending stack frame is the last one
			if (isset($frame['class'])) {
				//object scope
				$type = $frame['class'] . $frame['type'] . $frame['function'] . '()';
			} else if (substr($frame['function'], -9) === '{closure}') {
				$type = 'a closure';
			} else if (substr($frame['function'], -13) === '__lambda_func') {
				$type = 'an anonymous function';
			} else {
				$type = $frame['function'] . '()';
			}
		}

		throw new \LogicException(sprintf('You tried to set an object in the cache from %s, plz stop.', $type));
	}

	parent::offsetSet($key, $value);
}

I’ve never felt so dirty. This actually works, too.

$cache = new ObjectCache(
  function ($key) {
    return new \ReflectionClass($key);
  },
  function ($value) {
    return $value instanceof \ReflectionClass;
  }
);
$stdclass = $cache['stdClass']; //ok
var_dump($stdclass);
var_dump($stdclass === $cache['stdClass']);

class Foo {
	function bar(ObjectCache $cache) {
		$cache['foo'] = new \ReflectionClass('ReflectionClass');
	}
}

$foo = new Foo();
$foo->bar($cache); //LogicException: You tried to set an object in the cache from PhpMvc\Descriptor\Foo->bar(), plz stop.

$cache['foo'] = new \ReflectionClass('ReflectionClass'); //LogicException: You tried to set an object in the cache from {main}, plz stop.

$lambda = function() use ($cache) {
	$cache['foo'] = new \ReflectionClass('ReflectionClass');
};

$lambda(); //LogicException: You tried to set an object in the cache from a closure, plz stop.

function func(ObjectCache $cache) {
	$cache['foo'] = new \ReflectionClass('ReflectionClass');
}

func($cache); //LogicException: You tried to set an object in the cache from PhpMvc\Descriptor\func(), plz stop.

$func = create_function('$cache', '$cache[\'foo\'] = new \ReflectionClass(\'ReflectionClass\');');
$func($cache); //LogicException: You tried to set an object in the cache from an anonymous function, plz stop.

Let’s just forget we ever saw that…

#2: Override offsetSet()

Like I mentioned earlier, this will require a bit of refactoring, because Collection hides the internal data storage from derived classes.

class Collection implements ArrayAccess, Countable, Iterator {

	private $validator;
	private $data;
	private $index;
	private $numericIndex;

	public function __construct(Closure $validator = null) {
		$this->validator = $validator ?: function($value) { return true; };
		$this->index = 0;
		$this->numericIndex = 0;
		$this->data = array();
	}

	//snip

	protected function valueIsValid($value) {
		return call_user_func($this->validator, $value);
	}

	public function offsetExists($key) {
		return array_key_exists($key, $this->data);
	}

	public function offsetGet($key) {
		if (!$this->offsetExists($key)) {
			throw new OutOfBoundsException('The key "' . $key . '" does not exist in the collection');
		}

		return $this->data[$key];
	}

	public function offsetSet($key, $value) {
		if (!$this->valueIsValid($value)) {
			throw new InvalidArgumentException('This collection does not allow values of type ' . (is_object($value) ? get_class($value) : gettype($value)));
		}

		//instead of $collection[] = $value, do $collection[null] = $value
		if ($key === null) {
			$key = $this->numericIndex++;
		}

		$this->data[$key] = $value;
	}

	public function offsetUnset($key) {
		unset($this->data[$key]);
	}

	//snip

}

What we can do is factor out the actual setting of the data into a protected function that offsetSet() and all derived classes can use.

protected final function set($key, $value) {
	if (!$this->valueIsValid($value)) {
		throw new InvalidArgumentException('This collection does not allow values of type ' . (is_object($value) ? get_class($value) : gettype($value)));
	}

	//instead of $collection[] = $value, do $collection[null] = $value
	if ($key === null) {
		$key = $this->numericIndex++;
	}

	$this->data[$key] = $value;
}

public function offsetSet($key, $value) {
	$this->set($key, $value);
}

And then in ObjectCache, we just call set() from offsetGet(), and throw an exception if someone tries to call offsetSet(). While we’re at it, let’s make a get() method so we can avoid the call super anti pattern as much as possible. Now our get and set methods in ObjectCache are much cleaner:

public function offsetGet($key) {
	if (!$this->offsetExists($key)) {
		$this->set($key, call_user_func($this->creator, $key));
	}

	return $this->get($key);
}

public function offsetSet($key, $value) {
	throw new LogicException('Cannot set objects in the object cache');
}

In Conclusion

Closures are fun. Learn to love them.

Write a program that causes the url said (e.g. http://localhost:port/said) to produce a page with an input field and a submit button. When the submit button is pressed, that should produce a second page with a single link saying “click here.” When that is clicked it should lead to a third page that says “you said: …” where … is whatever the user typed in the original input field. The third page must only show what the user actually typed. I.e. the value entered in the input field must not be passed in the url, or it would be possible to change the behavior of the final page by editing the url.

I ignored the part about what the URL has to be, because that would just be annoying. The point of Arc is to write things in the most efficient way possible, and the whole language is built around helping you do that. The point of this problem is to illustrate that Arc does this very well.

In Arc, a solution looks like this:

(defop said req
  (aform [onlink "click here" (pr "you said: " (arg _ "foo"))]
    (input "foo")
    (submit)))

In PHP:

session_start();

if (isset($_SESSION['said'])) {
	echo 'You said: ' . htmlentities($_SESSION['said']); //prevent XSS lol
	unset($_SESSION['said']);
} else if (isset($_POST['said'])) {
	$_SESSION['said'] = $_POST['said'];
	echo '<a href="">Click here!</a>';
} else {
	echo '<form method="post" action=""><input type="text" name="said"/><input type="submit"/></form>';
}

And in JavaScript:

function getCookie(name) {
	var cookies = document.cookie.split(";");
	for (var i = 0, len = cookies.length, cookieParts; i < len; i++) {
		cookieParts = cookies[i].trim().split("=");
		if (cookieParts[0] === name) {
			return cookieParts[1];
		}
	}

	return null;
}

var said = getCookie("said"), page = parseInt(getCookie("page"));
if (said === null) {
	var input = document.createElement("input");
	input.type = "text";
	var button = document.createElement("button");
	button.appendChild(document.createTextNode("Submit"));
	button.onclick = function() {
		document.cookie = "said=" + input.value;
		document.cookie = "page=2";
		window.location.href = window.location.href;
	}

	document.body.appendChild(input);
	document.body.appendChild(button);
	document.cookie = "page=1";
} else if (page === 2) {
	document.cookie = "page=3";
	var link = document.createElement("a");
	link.href = "";
	link.appendChild(document.createTextNode("Click here"));
	document.body.appendChild(link);
} else {
	document.body.appendChild(document.createTextNode("You said: " + said));
	var expires = new Date();
	expires.setDate(expires.getDate() - 100);
	expires = expires.toGMTString();
	document.cookie = "said=;expires=" + expires;
	document.cookie = "page=1";
}

The cookie handling could probably be more compact, but whatever; the hideousness of that is far outstretched by the hideousness of the DOM. Try each of them out here:

• PHP
• JavaScript

Arc seems like a cool language. Too bad it’s based on Lisp, which means it will never get any traction in the demographics that don’t wear suspenders.

This seems to one of the most difficult things for someone to explain. Hopefully this will shed some light on the subject of PHP Windows compilation and help you out.

There don’t seem to be any “Compile PHP on Windows x64″ guides, and even less than zero for the VC9 compiler (VC9 means Visual Studio 2008). I pieced together what I could from other guides I found (all were either woefully incomplete, confusing, and for either 32-bit or older VC versions) and created this guide. Hopefully it helps. My environment looks like this:

• Windows Vista Home Premium 64-bit Windows 7 Professional 64-bit
• Visual Studio 2008 Pro SP1

Let’s begin.

Preamble

A word of warning. This is a guide to compiling PHP for development. If you’re looking for a production-ready PHP binary for Windows 64-bit, you’re barking up the wrong tree, in many different ways.

1. This is mostly a guide for those of us who develop on Windows with Apache. You shouldn’t be running Apache on Windows in production anyway, so if that’s what you’re looking for, you need to reevaluate your programming skills. PHP itself provides x64 VC9 binaries, but they’re not linked against Apache.
2. I know almost nothing about C/C++. Compiling PHP requires no knowledge of C/C++. I only know enough to install what I need to make everything work.
3. If you all you want is a PHP 5.2 binary for Windows 64-bit, go here and go wild. If you want to compile PHP on Windows 32-bit, go here; it’s a good guide (it’s what got me started). If you’re looking for a Windows 64-bit PHP 5.3 binary download, get it from me here.

If you’re looking to compile some futhermucking PHP on Windows 64-bit, read on.

Let’s get retarded

You need to download a bunch of crap. I hope you have a lot of disk space.

• Windows Vista SDK Update (you only need this if you’re on Vista)
• .NET Framework SDK – A note about this: there are several newer versions of the SDK, and it probably won’t matter which one you use. I didn’t need this at all since VS2008 Pro installed the SDK for me (at least on Windows 7).
• Visual Studio 2008 C++ (I used the full version, but the express version should work, too)
• Something that lets you mount an iso, like Daemon Tools Lite (use Virtual Clone Drive if you’re on Windows 7)
• Build dependencies
• PHP source code
• 7-zip

This will get you setup to compile PHP linked against Apache 2.2. This builds the CLI, CGI and apache2handler SAPIs (not ISAPI, if you want IIS, download it from PHP).

Let’s do it!

First (only if on Vista), download Daemon Tools Lite (or Virtual Clone Drive) and install it. You might have to reboot. Then download the Vista SDK update and right click on the Daemon Tools tray icon, and mount the SDK .iso. It should autoplay, so allow it and follow the installation instructions. This will take a while. If there’s a checkbox related to the installation of 64-bit stuff, make sure it’s checked. Like this:

Second, download Visual Studio 2008 and install it. Make sure to check 64-bit related stuff, like this:

Go to your start menu, and you should see something similar to this:

That’s the x64 compiler command prompt. It’s a cmd shortcut that sets up all the environment variables needed to compile a C/C++ library for the x64 architecture. It’s important. Yes, my user icon is the stock cat picture. What?

Thirdly, if you don’t see something related to the Windows SDK in your start menu, download the .NET SDK and install that. Always check any 64-bit related stuff.

That was the hard part. Since it’s Windows (Windows Vista, even), I suggest you reboot. Let’s not upset her now. You’ve gotten this far only by her grace.

Now, download and install 7-zip. It’s a free, open-source archiving tool. Stop using stupid crap like WinRar. You aren’t downloading torrents in 1998 anymore. Then download the PHP build dependencies I created just for you and extract it to a clever place, like c:\php64. Then download and extract the PHP source code (you can get the bz2, since 7-zip can handle that) to c:\php64. Your directory structure should look like this:

- php64
-- php-5.x.x
-- deps

You are now ready to begin building stuff.

Compiling

Now it’s time to lift up your skirt and see if you got a pair.

First, a little explanation. The deps directory contains all the headers and libs that PHP needs to compile the different extensions (like curl for example). These came from PECL except for the apache libs, which came from blackbot. The stuff in the bin directory came from the binary tools provided by PHP here. As near as I can tell, the extensions need to be compiled with VC9. Apache was apparently compiled with VC8, which didn’t really seem to matter. I don’t know. The point is, all of these headers and libs work for what you are about to do, and that’s all that really matters. Right?

Here we go

Open up the x64 command prompt I alluded to earlier via the start menu, and cd to your php64 directory. The environment variables are all set up except for the binary tools (bison, zip and the like), so we need to modify the path. Do this:
path = %PATH%;c:\php64\deps\bin
echo %PATH%
That should modify your path and then spit it out. Mine looks like this:

Now we are ready to start the compilation process. I suggest you build the simplest possible version of PHP you can, and once you’ve gotten that to work, you can start enabling extensions. Or , if you’re man enough, you can skip right to the big finish and try compiling everything at once. I’ll walk you through the easier way.

cd into the php-5.x.x directory and type buildconf. This will (re)build the configuration file. Then run cscript /nologo configure.js --help This will show you a list of possible configuration switches.

The first build

We’re going to a very simple build that has most stuff disabled. Use this configure statement:
cscript /nologo configure.js --without-t1lib --without-xml --without-dom --without-simplexml --disable-xmlreader --disable-xmlwriter --without-iconv --disable-zlib --without-gd --disable-zip --disable-odbc --without-libxml

This won’t create a super useful PHP binary, but it’ll make sure that you have the ability to build PHP with no external dependencies. Type nmake to build. This will take about 5-10 minutes if there are no problems. If you’re watching it build, don’t be alarmed if it sits at parse_date.c for a minute or so: that’s normal. You’ll see a ridiculous amount of warnings, most of them about conversion issues. Disregard them.

When the build is done, cd to x64\Release_TS and type php -v to see your PHP version. Type php -m to see a list of all the modules we just compiled.

Congratulations! You just compiled PHP on 64-bit Windows. You are among an elite group.

Extension Hell

Now, it’s time to make this PHP binary useful. It’s time to compile in some extensions.

Most of these extensions are built statically, which means they’re compiled into PHP and cannot be enabled/disabled; in effect they are always enabled. A few of them (gd, curl) are compiled as shared, which is what you’re probably used to, where you have a php_[extension name].dll line in your php.ini that you uncomment/comment with reckless abandon.

Let’s start easy, by enabling some more core extensions, like iconv and the xml stuff. cd back to the php-5.x.x directory and use this configure statement:
cscript /nologo configure.js --without-t1lib --without-gd --disable-zip --disable-odbc

When you run that, you should see a pretty list of enabled extensions. That list should now have xmlreader, xmlwriter, iconv, libxml, xml and dom in it.

If the configure statement failed, you probably don’t have your libs set up correctly. They should be in a directory called “deps” that is a sibling to php-5.x.x. If they are, and it still didn’t work, then add this to the configure statement: --with-php-build=c:\php64\deps. That will force the PHP build system to look for libs in that directory (by default it looks in ..\deps). You can troubleshoot configure errors by looking at the output. Most errors should be something like “Not found” for headers/libs.

Type nmake to build and wait for another 5-10 minutes. Verify that your extensions were built correctly by checking out the modules:

If you’ve made it this far, you’re pretty much home free. All that’s left is enabling the apache2handler and the other extensions you want. The php64-deps.7z I made contains the headers and libs for the extensions that were easily available (i.e. the ones that PHP provided). If you need something more, like memcached for example, you’ll have to either build it yourself or scour the internet in the hopes that somebody already built it for Windows x64 (unlikely).

The Big Finish

Run this configure statement:
cscript /nologo configure.js --enable-apache2-2handler --with-curl --with-xsl --with-mcrypt --with-openssl --with-mysql --enable-sockets --enable-pdo --with-pdo-mysql --enable-soap --enable-mbstring --without-t1lib --with-pdo-odbc --with-bz2 --with-ldap --with-tidy --enable-exif --enable-mbregex --with-gettext --enable-shmop --enable-prefix=c:\lib\php --with-sqlite3 --with-xmlrpc --enable-zend-multibyte --with-mysqli

One note about the --enable-prefix switch: after building, you can run nmake install to install PHP to the directory you specify with this switch. Change the value to where you want PHP to be installed on your machine, or don’t run nmake install at all (it’s not required).

You’ll probably need to clean up the build output first. The easiest way to do this is to just delete everything in the x64\Release_TS directory. Now run nmake, wait another 5-10 minutes, and hope that everything worked.

Installation

A few of the extensions require some openssl binaries, namely ssleay32.dll and libeay32.dll. I’ve included these in the deps directory. You’ll need to copy them to wherever your php.exe binary is located. If you try to run PHP and Windows borks an error at you about PHP needing to close, then most likely it was looking for these dlls and didn’t find them. You’ll get that error if you try nmake install. It’s not serious, just copy those dlls and everything should be fine.

To enable curl and gd you’ll need to enable them in your php.ini… which means you need a php.ini. I’d just download one of the Windows zip packages from PHP and extract the php.ini-recommended or php.ini-development into your PHP binary’s directory. Make sure to change the extension_dir to the location of those dlls.

That’s it

And we’re done. Hopefully that all worked. Here are some common errors and how to troubleshoot them:

• Unresolved externals: this means that the headers are referencing things that don’t exist. This means that you’re screwed, and you should try and find headers that don’t have this problem. Or, if you know C, you can try and fix it yourself.
• Can’t find file: this means one of your source files (probably for an extension) is in the wrong place. You shouldn’t have this problem if you’re using my build dependencies archive. Regardless, this one’s an easy fix: just find the file and put it in the right place.

One last note, Fusion X-Lan has been providing pre-compiled Windows 64-bit binaries for a while, but it hasn’t been updated since PHP 5.2.5. The whole reason I wanted to compile PHP was so that I could run PHP 5.3 on my new 64-bit computer. Their binaries are much better than mine: they have all the extensions available, including the apache2 SAPI. Unfortunately, they’re old (almost two years now) and they also use the VC8 (or earlier) compiler. If you need PHP 5.2, use theirs. If you want to compile PHP 5.3 with VC9, use this guide, or just download the binary packages I provide.

I hope this was helpful. Leave a comment if you have any problems or find an issue with this guide.

Anyway, at the end, he called for transliteration implementations in languages besides ones that suck (my words, not his); here of course I’m referring to Perl, Python and Java. Luckily, PHP is so blindingly awesome that it only requires a function call to do such things. No compiling extensions or importing libraries.

$string = 'Möbius FTW because my name is Rölph Diäålysis';
echo $string . "\n" . iconv('UTF-8', 'ASCII//TRANSLIT', $string);

//The console says this:
/*
Möbius FTW because my name is Rölph Diäålysis
M"obius FTW because my name is R"olph Di"aalysis
*/

Obviously, it’s not totally perfect (it tries to approximate the look of them as closely as possible, which is why quotation marks replace the umlauts). This is compiled into PHP by default unless you’re stupid and decide to disable the iconv extension for no reason. Don’t do that. I believe it’s un-disablable in PHP 5.3.

You can also use the strtr function, but then you have to pass the translation characters yourself.

$string = 'Möbius FTW because my name is Rölph Diäålysis';
echo $string . "\n" . strtr($string, array('ö' => 'o', 'ä' => 'a', 'å' => 'a'));

//The console says:
/*
Möbius FTW because my name is Rölph Diäålysis
Mobius FTW because my name is Rolph Diaalysis
*/

You could fairly easily and non-painlessly write a reusable library function in PHP using strtr() that will convert from unicode to ASCII, in the spirit of this.Obviously you wouldn’t want to write a conversion array for 65000 unicode characters, but you could at least do the characters you use most often.

Another option is the translit PECL extension. This would require you to compile an extension, though.

I just posted this to the PHP comments, but I figured I’d put here as well. The stat() suite of functions isn’t available to the HTTP stream wrapper in PHP, so if you’re using readfile() to handle downloads (for example, like I was), and it’s coming from a remote site (like it was), then this is useful.

Using the Content-Length response header is very useful for downloads because it is what displays the progress bar and estimated time left to the user; otherwise, they just see “unknown”, which is annoying because they won’t know if they’re downloading something that is 4GB or 4KB. And that letter makes all the difference.

Anyway, use this code.

$remoteFile = 'http://us.php.net/get/php-5.2.10.tar.bz2/from/this/mirror';
$ch = curl_init($remoteFile);
curl_setopt($ch, CURLOPT_NOBODY, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true); //not necessary unless the file redirects (like the PHP example we're using here)
$data = curl_exec($ch);
curl_close($ch);
if ($data === false) {
  echo 'cURL failed';
  exit;
}

$contentLength = 'unknown';
if (preg_match('/Content-Length: (\d+)/', $data, $matches)) {
  $contentLength = (int)$matches[1];
}

header('Content-Length: ' . $contentLength);
header('Content-Disposition: attachment; filename="' . basename($remoteFile) . '"');
readfile($remoteFile);

Using the CURLOPT_NOBODY cURL option forces cURL to send a HEAD request instead of a GET request. The difference between the two is that HEAD only retrieves the headers. So even if the file you’re requesting is 100GB, it will take the same amount of time for a HEAD request as a file that is 100KB.

For example, doing this:

$contentLength = strlen(file_get_contents($remoteFile));

accomplishes the same thing, but it retrieves the entire body of the resource, which is very, very bad if it’s a very large resource. Not to mention the extra memory required to store the contents of the remote file. Stick to the HEAD requests. I knew they were good for something.

function array_flatten($arr) {
	$flattened = array();
	if (is_array($arr)) {
		foreach ($arr as $value) {
			$flattened = array_merge($flattened, array_flatten($value));
		}
	} else {
		$flattened[] = $arr;
	}

	return $flattened;
}

Usage:

$a = array(
	'foo' => 'bar',
	'baz' => array(1, 2, 3, 4, 5),
	'bat' => array(
		'a',
		array(
			'b',
			array(
				'c',
				array('d')
			)
		)
	)
);

print_r(array_flatten($a));

/*
Array
(
    [0] => bar
    [1] => 1
    [2] => 2
    [3] => 3
    [4] => 4
    [5] => 5
    [6] => a
    [7] => b
    [8] => c
    [9] => d
)
*/

This version is interesting, but using create_function() is rarely a good idea, since it’s never garbage collected.