While every developer has kind of accepted their existence, they are suddenly there when we'd desperately need them to not show up. How often did you writeif($obj === null) in your PHP code? Can't there be a better, more elegant and fault-tolerant solution to the problem?

His solution is to create a PHP version of this "Optional" functionality (via an abstract class) that allows some evaluation of the returned value from method calls on the object. Methods like "isPresent", "getOrElse", "of" and "fromNullable" make it easier to work with null values instead of just the triple-equals checking. He includes not only the code for the classes you'll need to implement it but examples of it in use - an "Optional" abstract class and two child classes, "Present" and "Absent".

The other day I uploaded a new experimental project on GitHub - A Haskell PHP parser / evaluator. It doesn't understand 100% of all PHP syntax, but it was an interesting experiment nevertheless. Here's some insights and other thoughts from working on the code.

He gets the "why?" question out of the way early, noting that it was mainly a desire to play with Haskell and figured parsing something he already knew well was a good first project. He also mentions the "Parsec" library that seems well suited for the parsing part of the process. There were some issues that he came across, however including dealing with PHP's weak typing and handling all of the possible incarnations of PHP script structure. He includes an example AST showing his different data structures (PHPValue, PHPExpr and PHPStmt). The next part of the series will be more about the evaluation of this structure.

My company needs to hire a PHP developer, but nobody has PHP knowledge in my company and we find difficult to test for PHP skills. If it were a C/Java developer I would ask him to write a quick implementation of the Game of Life, but PHP is a completely different language. I saw this test with interest. Anyone else has more suggestions?

There's several other suggestions made touching on a wide range of evaluations including:

• Security concerns (like SQL injection)
• Debugging/Profiling
• Framework experience
• Good overall development skills
• And inks to other similar questions

We are currently building yet another PHP Cloud Platform ourselves. Of course we looked around to see what the others are up to. This is my (Franks) personal point of view of the current market situation showcasing my favorite services. I try not to judge, neither i will compare features nor prices.

Services on his list include:

• Heroku
• phpFog/appFog
• PagodaBox
• CloudControl
• EngineYard

Recently I needed to process a huge array of data and because of PHP's somewhat inefficient variables and especially arrays that was resulting in "out of memory" errors. However, I couldn't use any other tools than PHP so was forced to come up with a solution implementation in it. Here is how I solved it using principles from functional languages.

He gives an example using Haskell to generate a Fibonacci sequence using its built-in lazy evaluation abilities. Unfortunately, PHP doesn't have such a thing built in, so he tries the next best thing - Iterators. He caries the idea over to the database side too, recommending fetch() in a loop over fetchAll() and some effective joins.

There have been no fewer than 4 different proposals floated before, but this one combines flexibility, performance, intuitiveness, and minimal architectural changes, and has only a couple of small drawbacks. Let's take a closer look.

He details the functionality - what it is, what's been decided on, and the advantages of the method. The basic approach is a "lazy" one where PHP will only store the request when it comes in, no filtering or anything, until you want to do something with it (i.e. get it via $_GET, $_POST, etc). When the request for data is made, PHP looks at the encoding settings and formats the data accordingly.

Advantages he mentions for this method include removing the guess-work on PHP's part for which encoding the request is and that it removes some of the overhead by not processing the data until it's actually needed.