Derick Rethans has a post to his site covering some optimizations around PHP's "switch" handling and how it has changed in the upcoming PHP 7.2 release.

PHP 7.2 is around the corner soon, and comes with many optimisations. Many new optimisations are implemented in opcache, but some others are implemented in PHP itself. One optimisation that falls in the latter category is an optimisation of the switch/case construct.

He then gets into the differences between the previous functionality and how it has changed, mostly in how the language handles the evaluation of the "case" statements. He include a flow diagram of how the pre-7.2 flow happened and how, with PHP 7.2, a "jump table" is used to optimize the process. This table allows PHP to perform a lookup on the value rather than evaluating equality (like in an if) on string values. If it's not a string the same evaluation happens as before, however.

In a new post to his site Benjamin Eberlei takes a look at the idea of "feature flags" (settings to turn on and off major features) and how they can be used with Doctrine entities to handle sync issues between new properties and the database schema.

The problem of feature flags with Doctrine is easily explained: If you add properties for a new feature that is disabled in the Doctrine metadata, then you need to upgrade the database before deployment, even when the feature is not being rolled out for some days/weeks. Doctrine requires the database to look exactly like the metadata specifies it.

His solution was to use the "loadClassMetadata" event in the entity to dynamically append these new properties based on simple "if" checks of feature flags in the configuration object. Obviously using this is a bit of a hack until the new properties are in place, but once they are then the only change is removing this code.

In this new post to his site Chris Hartjes gives an example of what he calls a "testing smell". This particular illustration deals with the poor handling of testing and exceptions with try/catch blocks.

As part of a project to migrate the PHP code at work from PHP 5.2 to PHP 5.4, I’m using our extensive test suite to look for instances where something that changed between the versions of PHP that we are using has caused some unexpected behaviour. In one of our code bases, I found some tests that are exhibiting a test smell through their use of a try / catch block in the test itself.

He includes a (contrived) example showing the use of an exception in a unit test to run an assertion in the "catch" for the test to pass. He points out that this particular check is being done to see if the user input is valid...and that it's a bad way to enforce it using exceptions. He also suggests that if you have an "if" situation, don't use one test with logic in it, write two tests. He mentions a disenting opinion but notes that a failing test is a failing test, regardless of what caused the failure.

Improving on his last post about creating a bytecode compiler in PHP, the Sankuru blog has a new post in the series looking at extending the basic compiler to add support for if/while and do while logic.

In order to obtain a turing-complete programming language, that is, a language in which we can implement and execute any arbitrary algorithm, that is, that other turing-complete machines can execute too, we now need to add a way of (conditionally) branching, that is, the IF statement, and at least one way of repeating statements, that is the WHILE or the DO WHILE statements.

He includes a simple TL-based script as an end goal for the compiler to be able to execute and shows how to add rules for it to the lexer/parser. Rules for the "if" are relatively simple, but there's a hitch in dealing with embedded "while" statements he had to work around. The post ends with the bytecode results for the sample program and the resulting output from the compiled versions execution.

On PHPMaster.com today there's a new tutorial showing the use of a sometimes overlooked (but very handy) alternate syntax that PHP includes - the ternary operator, a short-hand if/else.

You’re probably already familiar with PHP’s if statement. It’s very similar to its counterparts in many other programming languages and represents one of the most fundamental concepts in programming. [...] But there’s a way to build on this concept and increase your $coolFactor a bit in the process. Allow me to introduce you to the ternary operator, which serves as a shorthand notation for if statements.

They introduce the ternary operator's syntax, the ":" and "?" operators and includes a few pieces of code showing its use. Thankfully they also include a warning - don't overuse or abuse it...and especially don't nest them - that just leads to headaches.

PHPBuilder.com has posted the eighth part of their introductory "ABCs of PHP" series today. This time the focus is on looping and decision functionality (like if/while/for/etc).

n any given computer language (PHP is no exception) there has to be a way to allow the running code to decide between doing 2 different things. If there wasn't then software would not be able to adapt based on operating conditions, or it wouldn't be able to decide between two different users.

They look at using: if statements and operators, for loops and while loops. When they look at the operators, they talk about the differences between equals/not equals, grater than/less than and two of the boolean operators - AND and OR.

On the "Ask About PHP" blog today there's a new post looking at some of the alternative syntaxes that PHP has to offer for control structures.

PHP offers an alternative way to write their control structures for as long as I’ve remembered. It basically does away with the curly brackets and replaces the opening curly with a colon (:) and the closing with ‘end’-whatever. I have to be honest and say I’ve never really found a need to use the alternative syntax, simply because I’m so used to using the curly braces after so many years of using PHP. Plus, it’s less typing!

The one specifically mentioned deals with "if" evaluations. There's two other options to the usual braces method - one being a shorthand using colons and a semicolon and the other using the ternary syntax.

Rob Thompson has posted about some simple benchmarking he did comparing the speed of a series of "if" statements versus one "switch" with multiple cases.

I got curious about which is actually more efficient at matching a random integer with a set of conditionals. So, I setup a script to create a set of large scripts to test the speed of these different constructs. Using the 'time' command, I measured the speed at which the condition could match a random number.

His results found that the switch statement is generally more than 2 times as fast at matching a simple integer. His tests, however, didn't go through much more than this simple test. It'd be interesting to see what it would do with something more complex (like longer strings or handling the result of an evaluation inside the definition of the switch().

Kore Nordmann has made a quick post to his blog about some "evil bugs" he's seen reoccurring in the code he writes and wanted to point them out so other developers might learn from them.

Those are 4 typical errors I introduced in my code, and spend some time debugging it, because I found them really hard to spot. Luckily, once I spotted the actual bug, I find it a lot easier the next time the typo occurs. Therefore I want to share those, so that I may save you some minutes of your life hunting stupid bugs.

His three contributions concern a "missing if", the addition of a random semicolon, operator precedence and a for loop that refuses to work. Others have contributed to the comments on the post as well.

Kore Nordmann has made a quick post to his blog about some "evil bugs" he's seen reoccurring in the code he writes and wanted to point them out so other developers might learn from them.

Those are 4 typical errors I introduced in my code, and spend some time debugging it, because I found them really hard to spot. Luckily, once I spotted the actual bug, I find it a lot easier the next time the typo occurs. Therefore I want to share those, so that I may save you some minutes of your life hunting stupid bugs.

His three contributions concern a "missing if", the addition of a random semicolon, operator precedence and a for loop that refuses to work. Others have contributed to the comments on the post as well.