On his site recently Alex Zorin posted an article about shimming PHP for fun and profit making use of the runkit functionality to override some of the basic PHP handling.

I had spent a short amount of time profiling the application some months ago. By all indications, the framework upon which the site was built was doing something really stupid.

[...] For somebody who is comfortable finding and fixing hotspots like this, it sounds like a dream come true. Not so. A quick grep through the code indicated that that particular hotspot existed in at least a dozen different points in the code base. As my role in this scenario was an ops. engineer, touching the client’s codebase was a no-no.

He first looked into something he could add at the Zend Engine level itself but then veered more towards custom functionality that overrides some base64 handling in the language. There were some difficulties following this path so he shifted to another tactic - using runkit. He implemented this "monkey patching" solution using the runkit handling and integrated it into his client's installation reducing the load time by about 10 seconds on the largest, slowest request he could find. He also includes a link to the code if you're interested in seeing how he accomplished this optimization.

In this new post to his blog Chris Hartjes looks at why "monkey patching is for closers" - how it should be avoided in favor of making the code itself more testable rather than "hack" with the patching.

The use of monkey-patching is extremely prevalent in the Ruby community and also to a certain extent in Python usage. I’m not going to go into length about their use of it except to say that it seems quite common and I think most developers are using it as a shortcut to counter what might be poor code architecture decisions.

He includes some example code, excerpted from a blogging system where runkit was originally use to test its functionally. He shows how some simple refactoring (adding input parameters, replacing a static method call, etc) makes it easier to unit test. Comments to the post include further refactoring ideas as well as a response from the original "offender" whose post sparked Chris' response.

Kurt Payne has a new post to his blog showing how you can unit test your process forking in your PHP application (pcntl).

At some point, many php developers turn to the pcntl functions in php to write a daemon, or server, or simulate threading. But how do you unit test this with complete code coverage? [...] We need to engage some black arts php extensions to make this happen. An installation guide follows, and the post ends with a complete listing of the unit test.

He uses the test_helpers extension (as provided by Sebastian Bergmann) and Runkit to allow the test to define new methods copying the current pcntl methods and mocks up the responses. Tests are included to check the parent of a process, checking the children of a process and testing that a fork could be made. Hes's even included visual proof of this working.

In a new post to his blog today Till Klampaeckel takes a look at monkey patching in PHP - a way to replace functions at runtime.

I haven't really had the chance or time to play with PHP 5.3 until recently when Ubuntu 10.04 upgraded my local installations and kind of forced me to dive into it a little. And I'm also probably the last person on the planet to notice, but namespaces in PHP 5.3 allow you to monkey-patch core PHP code. [...] One of the more common applications is stubbing (or mocking) code in unit tests.

He includes a code sample showing how you can use a simple namespace hack to call a function from another namespace named the same as an internal one - in this case strlen.

Benjamin Eberlei has a suggestion for testing your application without having to mess around with creating new resources just for testing - use mocks.

Much talking is going on about Unit testing, Mocks and TDD in the PHP world. For the most this discussions surround object-oriented PHP code, frameworks and applications. Yet I would assert that the reality for PHP developers (me included) is dealing with PHP 4, PHP 5 migrated, or non-object oriented legacy applications which are near to impossible to bring under test.

He includes a "proof of concept" for a replacement mysql_query function (as created inside of Runkit) that sets up a "mocker" object that returns a "hello world" message when the mysql_query function is called.

In response to this post on the ActsAsFlinn blog's comments on ActiveRecord in PHP, Arnold Daniels has some comments of his own on the subject - specifically about the need for more work on the object oriented side of things in PHP natively.

Today I read an article about how Active Record is implemented in Ruby. In this article he lays down how things are done in Ruby and how that is not possible on PHP. Though I agree with him on a large part, there are a few site notes to make here.

Arnold talks about a solution to an issue mentioned in the ActsAsFlinn blog - the addition of methods to a preexisting class - via the runkit extension. He gives a PHP translation of the Ruby code from the other post and includes a few proof of concepts to show it in action. You can download the code if you'd like to try it out yourself.

In response to this post on the ActsAsFlinn blog's comments on ActiveRecord in PHP, Arnold Daniels has some comments of his own on the subject - specifically about the need for more work on the object oriented side of things in PHP natively.

Today I read an article about how Active Record is implemented in Ruby. In this article he lays down how things are done in Ruby and how that is not possible on PHP. Though I agree with him on a large part, there are a few site notes to make here.

Arnold talks about a solution to an issue mentioned in the ActsAsFlinn blog - the addition of methods to a preexisting class - via the runkit extension. He gives a PHP translation of the Ruby code from the other post and includes a few proof of concepts to show it in action. You can download the code if you'd like to try it out yourself.

David Sklar points out an issue that keeps coming up over and over again in the course of object-oriented applications - why the static keyword doesn't know about inheritance.

There are plenty of good reasons why PHP 5 works this way and it seems that in PHP 6 the static keyword will be able to be used in place of self to get the dynamic behavior a lot of folks are looking for. [...] All well and good once PHP 6 is done.

In the meantime, I was noodling around with runkit and came up with some glue that lets you do something like this.

In his runkit example uses a glue class called MethodHelper that uses various things (including some reflection) to manually look into the classes and find the static information.

A fun proof of concept, but not something (for efficiency reasons) you'd probably want to run on a busy production site.

David Sklar points out an issue that keeps coming up over and over again in the course of object-oriented applications - why the static keyword doesn't know about inheritance.

There are plenty of good reasons why PHP 5 works this way and it seems that in PHP 6 the static keyword will be able to be used in place of self to get the dynamic behavior a lot of folks are looking for. [...] All well and good once PHP 6 is done.

In the meantime, I was noodling around with runkit and came up with some glue that lets you do something like this.

In his runkit example uses a glue class called MethodHelper that uses various things (including some reflection) to manually look into the classes and find the static information.

A fun proof of concept, but not something (for efficiency reasons) you'd probably want to run on a busy production site.

If you've ever really found a time when you needed to overwrite one of PHP's bult-in functions with your own custom one (maybe a custom handler or the like), you might want to check out this post on OpenIdeasCompany.com.

The author needed to redeclare session_start in a few files to change the place the default sessions are located at (spanned across three machines). He didn't want to rewrite the application to make this change, so he used the runkit extension out of pecl (and the php-devel package) to create a solution redefining functions to match his needs.

Of course, there are some easier ways to accomplish what he needed, but it's still an interesting method if there's really just no other way.