On his Medium.com blog Liam Hammett has written up a tutorial explaining the functionality and use of bitmask constant arguments in PHP.

PHP has a handful of core functions that can accept boolean arguments in the form of constants that have a binary value.

These can be combined together in a single function argument, essentially passing multiple boolean flags in a very compact manner. They work a bit differently to how most people implement options in their userland functions, so let’s take a look at how they work.

He starts off by talking about how the PHP core language makes use of them in certain functions with an example of the JSON_THROW_ON_ERROR constant for use with json_encode (both as a single option and multiple using a bitwise operator). He then gets into the "code behind the code" and talk about how they work for both "OR" and "AND" types. He ends the post with an example putting all of this knowledge to use in an if that detects if a bit exists in the inputted constant list.

On his site Tomas Votruba continues his look at the Symfony/Console component of the Symfony framework. In this latest article he walks through the loading of configuration options from a file provided by a --config option on the command line.

PHP CLI apps usually accept config, to setup their behavior. For PHPUnit it's phpunit.xml, for PHP CS Fixer it's .php_cs, for EasyCodingStandard it's easy-coding-standard.yml, for PHPStan it's phpstan.neon and so on.

In the first post about PHP CLI Apps I wrote about poor DI support in PHP CLI projects.

Today we look on the first barrier that leads most people to prefer static over DI - how to load config with services.

He starts off talking about the "chicken and egg" issue when it comes to loading configuration: needing a configuration to create an Application instance which then needs the config (and so on...). He then walks through three possible solutions:

1. Not using a container to manage dependencies for the application
2. Setting up a container in a command
3. Using the ArgvInput input helper to pull directly from the arguments

He gets into more detail on this last method, providing code examples and input/output examples of it in use. Unfortunately this method also introduces some undesired dependencies between commands. He finishes the post with an alternative: setting up option definitions in the getDefaultInputDefinition method of the main application and having them available to all commands.

Robert Basic has written up a new tutorial for the unit testers out there showing how to do some complex argument matching in Mockery, a popular testing tool that offers an alternative to PHPUnit's own mocking functionality.

This past weekend I did some issue maintenance and bug triage on Mockery. One thing I noticed going through all these issues, is that people were surprised when learning about the Mockery::on() argument matcher. I know Mockery’s documentation isn’t the best documentation out there, but this still is a documented feature.

He starts with a simple mock example, mocking out AClass and defining two method criteria (one with a once and another with a never). He points out that things are not always that simple and sometime more complex argument matching is required. The Mockery:on handler allows you to pass in a closure and do more complex evaluation of the values passed in. He includes an example of this, evaluating the result of a set of arguments passed in and ensuring they're all set.

Freek Van der Herten has a new post to his site sharing some of his ideas around making overloaded functions more readable, functions that can take in variable types of parameters (ex: both a string or an array) and can handle them correctly.

Sometimes you might allow a function to accept multiple data types. I don’t know for certain if it’s the correct term but for the remainder of this post I’m going to call such a function overloaded. In this post I’d like to show you a little trick to make overloaded functions more readable.

He starts off with an illustration from the Laravel framework of a "session" helper method that, in turn, calls "put" and checks for an array versus string input with some interesting logic behind it. He gives another example from a recent pull request where the code could be simplified using the same method as the "put" example, making it much more readable in the end. The post ends with one more example from this package and how the "respond" method was refactored with the same process, simplifying it down to a more readable and less-nested version.

On the Ez.no blog there's an interesting post comparing PHP and Symfony to Java and some of their own reasoning behind the choice of one over the other.

We are often asked, especially from our enterprise customers at financial institutions, why we decided to go with PHP and Symfony instead of a Java framework. And as we have actually re-considered alternatives both in 2007 and 2011, we know the answer pretty well. We also know firsthand how much PHP and the PHP ecosystem has matured and progressed the last few years, how Symfony2 and Composer provided a big jump forward, how PHP v7 and Symfony3 is positioned to provide the next, in the end making us very confident in our choice and in recommending it to others.

They then talk about some of the arguments of PHP versus Java, some that are pretty familiar to those in the PHP camp:

• PHP is "just a scripting language"
• Java is more scalable
• PHP's performance is bad in comparison
• Poor tools support for PHP

For each of these they link to more information and describe the current state of PHP and its ecosystem to help refute the claim. They then get into the Symfony portion, comparing it to similar Java frameworks, listing advantages like the large pool of Symfony developers and its vibrant community.

Lorna Mitchell has a new post to her site looking at a feature of the upcoming PHP 5.6 release, the splat operator (three ellipsis...).

We have a couple of new features coming in to PHP 5.6 with names that sound much less exciting than the features they actually represent: "variadic functions" sound positively academic, and "argument unpacking" isn't exactly catchy. However they both use a new operator in PHP which looks like an elipsis (three dots ...) and is referred to as either the splat operator or the scatter operator. I included them in a recent version of my "Upgrading PHP" talk so I thought I'd share the examples here too in case anyone is interested.

She includes an example of it being used in a variadic function, one that lets you define an optional number of parameters without having to resort to func_get_args. She also talks about "argument unpacking" or the passing in of an array of values with the splat to have it handled like a string. An example with the mail function is included.

The CodeUtopia blog asks the online community for their opinion - what do you think of PHP as a first language?

Sometimes I've seen people say PHP is a bad first language, because it teaches bad programming habits. But is this actually true at all? Often those who say that don't really like PHP themselves either, many times because of equally untrue reasons.

They argue both sides of the situation, mentioning what could make for a good first language, why PHP is a "nearly perfect" fit for it and some arguing points for the other side as to why PHP isn't the best option.

Mike Naberezny has posted a few more articles to the "Rails for PHP Developers" website (based on this book) covering some more of the basics.

There's three new tutorials posted:

• Ruby Block Scope - the basics of Ruby block scope, a common point of confusion for PHP developers new to Ruby.
• Variable Arguments - an article that shows two common API patterns found in Rails, variable arguments and option hashes, and how to implement them both in PHP.
• Regular Expressions in Ruby - a useful reference that maps all of the common PHP regular expression functions to the equivalents in Ruby.

Check out the rest of the site for even more great content.

Jeff Moore mentions a "sweet improvement" he noticed when comparing the error message from a PHP4 script to a PHP5 one - the location reported for error mesages.

Sometimes its the little things that make a difference.

His sample script (a function call without the argument needed) errors on the location of the function definition in PHP4, but happily PHP5 recognized the problem for what it's worth and echoed out the location of the call to that function instead for the line number.

One more reason to ditch PHP 4 and go php 5.

Jeff Moore mentions a "sweet improvement" he noticed when comparing the error message from a PHP4 script to a PHP5 one - the location reported for error mesages.

Sometimes its the little things that make a difference.

His sample script (a function call without the argument needed) errors on the location of the function definition in PHP4, but happily PHP5 recognized the problem for what it's worth and echoed out the location of the call to that function instead for the line number.

One more reason to ditch PHP 4 and go php 5.