Simas Toleikis has posted an interesting idea for a validator that would look at the incoming source of an application/script and determine what the requirements for it might be.

How about creating a PHP code validator? Got this idea by looking at tokenizer and reflection extensions. I doubt I will find the time to work on this myself but then someone else might be interested to pick it up. From user’s point of view there will be a form made of a large textarea box and a single file upload input. One could paste code snippet on that textarea or upload a ZIP'ed source code archive (or a single .php file) for validation.

His proposed result would show a list of "Required Extensions", PHP versions, E_STRICT compatibility and possibly total lines of code in the project. He points out a few issues that might pop up in writing such a tool such as the requirement for it to be able to use the tokenizer extension itself (a sort of catch-22 since it's not always installed).

Jani Hartikainen has put together a handy script for those out there that like what the Zend Framework is all about but don't really need the whole thing to get the job done. If that's you, this script might be just what you need.

Did you ever want to use just a single component from Zend Framework, but couldn't figure out which files you needed? Well, here's a solution: Zend Framework packageizer script! Just pick the class you want, and you'll get it and all its dependencies in a nice zip file for you to consume.

The packager uses the tokenizer functionality PHP offers natively to look through the files for the package you're after and finds all of the files that might need to be included and pulls them right along into the zip file.

Joshua Thompson, inspired by another blog post on a use for the PHP tokenizer, has started off on a new project to expand on one of the examples - a preprocessor.

It makes a lot of sense for the library developer. They could easily create multiple versions of their code depending on PHP version, target platform, backend database, etc. So I started working on my own implementation of a preprocessor with the goal of making it easy to add plugins for additional functionality. It was during the construction of the core of the preprocessor, that it hit me: why can't we implement new language features in the preprocessor.

As a result, he's created his first version of PPP - PPP PHP PreProcessor (yes, recursive). It's a starting point that has a plugin for traits handling and a soon to come plugin to reduce the need for namespaces.

A new tutorial has been posted to php|architects C7Y community site looking at some practical uses of the PHP tokenizer to work with your source.

In this article we take a look at the PHP tokenizer and its potential at analyzing and processing PHP source code. We will build several working examples, which you can start using and extending for your own purposes.

The author, Stan Vassilev, explains what the tokenizer is for, how it parses the code (via a lexer) and how to get at the tokens that are created. He uses the token_get_all and token_name functions to get the information and creates a wrapper class around them to strip whitespace and comments.

Padraic Brady has made a post about some of the mutation testing thoughts running through his head for the Behaviour-Driven Development framework he's been working on - PHPSpec.

Mutation Testing is like testing, for tests. The idea is actually quite simple. Mutation testing adds small changes to your source code on the assumption that changing something, will most likely break it, which in turn means at least one test/spec should fail. [...] The reason why it's useful it that it gets around the problem of being over reliant on code coverage - just because some code executes when running tests, doesn't prove the tests will detect problems with it!

He wants to create a way that doesn't rely on external dependencies and is looking at working with the tokenizer functions native to PHP. He includes two examples of the way he's thinking - an example of simple token output and a way to go "backwards" to recreate the original source code.

Padraic Brady has made a post about some of the mutation testing thoughts running through his head for the Behaviour-Driven Development framework he's been working on - PHPSpec.

Mutation Testing is like testing, for tests. The idea is actually quite simple. Mutation testing adds small changes to your source code on the assumption that changing something, will most likely break it, which in turn means at least one test/spec should fail. [...] The reason why it's useful it that it gets around the problem of being over reliant on code coverage - just because some code executes when running tests, doesn't prove the tests will detect problems with it!

He wants to create a way that doesn't rely on external dependencies and is looking at working with the tokenizer functions native to PHP. He includes two examples of the way he's thinking - an example of simple token output and a way to go "backwards" to recreate the original source code.