On PHPMaster.com today David Shirey has a written up a new tutorial introducing the ctype functions in PHP. This set of functions provides a handy way to more correctly check values to ensure they're valid (and contain what they should).

If you have a background in C, then you're probably already familiar with the character type functions because that is where they come from (don't forget that PHP is actually written in C). But if you're into Python, then it's only fair to point out that the PHP Ctype functions have absolutely nothing to do with the Python's ctypes library. It's just one of those tragic and totally unavoidable naming similarities.

He briefly explains how the functions work and at least one "gotcha" to watch out for if you're using them for input validation. He then goes through the list of the eleven ctype functions and briefly describes what they do. Some example code is also included showing how you can use them to validate a value based on the true/false return from the function call.

Elijah Horton has a recent post to his site sharing a tool he's developed to sandbox and validate PHP code of user-contributed code.

Few quotes related to the PHP language are as pithy and resoundingly accurate as the phrase: "Eval is evil." The reasons are myriad: the eval() function basically gives whatever code is passed to it unlimited control of the parser, and this freedom makes eval() both a temptation for developers, who may need to dynamically control PHP at runtime, and a panacea for hackers who are ever-searching for more servers to add to their botnets. So, how does one make use of the extreme power available through runtime evaulation of PHP, without exposing one's server to near-certain rooting? Through a sandbox.

His tool - PHPSandbox, uses the PHP-Parser library to deconstruct the PHP code its given and look for issues. He gives an example of a call to mail and how it would catch the issue. He shows how to install it via Composer, how to configure it with whitelisted methods/functions. It also includes a way to overwrite function calls with a bit safer alternative.

On PHPMaster.com today there's a new tutorial for the Twig templating users out there showing you how to extend your templates via inheritance, filters and functions - all abilities already built in to the tool.

When working within an MVC architecture, it's common to use a template library to populate the dynamic content of our views. There are dozens of such libraries available for PHP, but Twig is one of the standouts because of the ability to extend core features with custom implementations. In this article we'll explore how Twig templates can be extended using template inheritance, filters, and functions.

He starts first with some of the common limitations of templating frameworks (extension) and how Twig gets around this. He shows the use of the "extends" keyword and the "block"/"endblock" for splitting up the page into reusable chunks. He also shows how to use filters and functions in your Twig tags, allowing for more customized content and functionality for your output.

Ben Ramsey has a new post talking about a feature that will become available in the PHP 5.5.x release series of the language - the array_column function. This function will extract all values from an array matching a given key.

My original patch for array_column() was written for PHP 5.2, but it sat around collecting dust for many years, until April of last year, when PHP moved to git and GitHub. That's when it became easy enough to apply the patch and send a pull request, which I did. [...] My goal for array_column() was simplicity. Many implement the functionality in different ways, and many call the function by other names (such as "pluck"), but I wanted to keep it simple and recognizable.

He includes an example of some sample data and how the function could be used to pull out the "last_name" field from each of the records and return just those as an array. If you're interested in seeing the original proposal and the RFC that was created for it, you can see it on the PHP wiki.

In this post to his site Brandon Savage talks about "always returning something" from your methods and functions back to the calling script. He also suggests that null is not an option.

A few weeks ago, there was a discussion on Twitter about whether or not a method should always return a value, or whether or not null was a valid value to return. The answer to this question is a resounding no, a null value should never be returned. [...] For example, you check that a file you opened exists, or that a resource performed correctly before using it. But if you receive a null response, how do you test for this The answer is you can't

He notes that a "null" response is not only difficult to test but can lead to ambiguous handling as you're not sure where the error might be. He also includes a snippet of code showing how a null response could break a fluent interface if an instance of "$this" is not returned.

Andrew Podner has posted an introduction to a concept in PHP that may not be easy to immediately grasp for someone relatively new to the language - the idea of lambdas and closures.

Beginning with PHP 5.3, the anonymous function, became available to developers as a means of improving flexibility and increasing the number of tools at our fingertips to build powerful PHP applications. What I have been seeing a lot of as I read through documentation is more frequent use of terms like lambda, closure, or anonymous function, and sometime the terms are often used interchangeably, so let's take a deeper look into what all of these things are and what differences, if any, there are between them.

The post looks at lambdas first, defining them as "functions without names" that can be assigned to objects or called inline when needed. Next is closures, and it's noted that, in PHP, there's really not much difference. They both also allow for use of the "use" statement to import values into the function's local scope. He mentions the "$this" update that came in PHP 5.4 and includes some arguments against their use too.

On Reddit.com there's a heated discussion going on in response to this bug filed asking about aliasing PHP function names to make them more consistent (specifically "htmlentities_decode" versus "html_entity_decode").

[...] Current naming conventions are really horrible. For instance, look at differences between str_replace, strlen, parse_str, htmlspecialchars. All work with same type but their names are completely different. So, string functions should go to String namespace (Stringreplace()), array functions to Array namespace (Arraysearch()) and so on.

Back in the Reddit post most of the commentors agree that this kind of thing would be beneficial to the language, but - as several point out - this could have serious backwards compatibility issues. What do you think? Voice your opinion!

Matt Frost has shared some of his work he's done with the SoapClient in PHP and how he mocked it out for his unit tests (since it's an external resource).

The concept of mocking web services for testability took a little while to sink in for me. A big part of it was that my job doesn't see me consuming web services all that often, but I had an opportunity to give it a shot with SOAP. I found that I learned a lot more about testing in general having worked through this. I used SoapClient and wrapped it, so here's a little bit about some of things I learned. Hopefully you don't have to work with SOAP, but if you do you can test it pretty easily.

He walks through the mocking of the client itself and how he handled it's ability to translate function calls into SOAP method calls (using "__call") and how he mocked that. He also makes the suggestion that you actually wrap the SoapClient inside of another class rather than trying to mock the actual SoapClient. He also touches on the testing of exceptions that might be thrown by the service and how he tested those using his wrapper class.

If you've been around PHP for any length of time, you know about the static functionality and keyword that the language offers. You might have used it in the past for a few things, but maybe you're not 100% sure of how to use it right. If this describes you, you should check out this article from David Zentgraf for a great summary of their use and how to not kill the testability of your application by using them,

"Class Oriented Programming" is what people do when they write classes which are all static methods and properties and are never once instantiated. I'll try to explain why this adds virtually nothing vis-a-vis procedural programming, what these people are really missing out on by ignoring objects and why, against all odds, statics don't automatically kill testability. While this article focuses on PHP, the concepts apply equally across many languages.

He talks about code coupling, expectations when using static classes/methods and how it seems a little too similar to some of the procedural PHP we all started out writing. He ponts out that most static method calls are more like function calls than true OOP methods and that their dependencies are a bit more difficult to manage. He suggests that statics are really only good for one kind of thing - dealing with already static data and "utility methods" operating on given data.

Timothy Boronczyk has written up a new post that looks at using assertions in PHP - the actual use of the assert function to evaluate values in your code.

I stumbled upon assertions in PHP today, though why I didn't know they existed after working with the language for so long and what I was looking for originally when I came across them are both mysteries. And with the increasing focus on software quality in the PHP community, I wondered why I hadn't seen them used by others. I decided to ask around, look into PHP's implementation of assertions, and do some tinkering.

He talks some about their usage, some of the common issues surrounding them and compares using them directly on return values vs evaled strings. He also includes an implementation of them in a bit of sample code - a class that uses them (and an assertion callback) to handle the throwing of exceptions.

Assertions are meant to identify program logic/design bugs, not as a run-time error handling mechanism. Isn't this why we do unit testing? Playing devil's advocate, what's wrong with pushing unit tests directly into your code if we have doc comments that are extracted for documentation?