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.

In a recent post to his site Simon Holywell covers immutability in PHP. PHP, by default, uses weak typing and doesn't support much in the way of immutability but Simon shows you a few ways you can get around this and make immutable objects you can use and extend.

Being a weakly typed dynamic language, PHP has not really had the concept of immutability built into it. We’ve seen the venerable define() and CONSTANTS of course, but they’re limited. Whilst PHP does ship with an immutable class as part of it’s standard library, DateTimeImmutable, there is no immediately obvious method to create custom immutable objects.

[...] It is possible to write your own immutables using some simple and sneaky PHP techniques though. We’re going to use a simplistic data requirement to make the examples in this article easier to follow. I’ll be using professional skateboarders and the tricks that they brought to the world.

He starts the article talking about immutability and how it relates back to the current (as of PHP 7) values supported in constants - scalars and arrays (no objects). He then starts on the code to create the base Immutable class that sets its values via the constructor. He then points out some of the common "work arounds" people use when trying to work with immutable objects and some techniques to help prevent it: the use of final, a "flag" preventing another constructor call, etc.

The PHP 7.1.x releases are some of the latest versions of the language. There's plenty of new features that came along with this new release. In this new post to his CodeDiesel blog Sameer Borate looks at some of these new features (including code snippets to illustrate).

The PHP development team announced PHP 7.1.0 on 01 Dec 2016. This release is the first point release in the 7.x series. There are a few features – like the void return type – which have been introduced. Below are a few new selected features in PHP 7.1.

In the post he covers:

• void functions (return type)
• nullable types
• symmetric array destructuring
• class constant visibility

For each, code samples are provided and some of the benefits (and limitations) that come along with them.

On the Symfony blog there's a quick post sharing helpful advice about fixing PHPUnit tests in Symfony 3.2 applications, mostly around an issue involving the use of the "phar" distribution and a class constant error.

If your application uses Symfony 3.2 and you execute PHPUnit via its PHAR file, you'll end up with the following error message [about the "PARSE_CONSTANT" constant]. In Symfony 3.2 applications you can't use the PHAR file of PHPUnit and you must use instead the PHPUnit Bridge.

They provide the commands to get this bridge installed (via Composer) and how to execute the PHPUnit tests post-install (using the "simple-phpunit" command instead). They explain why this process needs to be followed to run the tests correctly and how the PHPUnit-bridge package helps to resolve the situation.

In his latest post Rob Allen shows a handy way, making use of the http://php.net/getimagesize function, to determine the image type of a file based on header information returned.

One thing I learnt recently which I probably should have known already is that getimagesize() returns more than just the width and height of the image. [...] However, getimagesize() also returns up to 5 more pieces of information. Interestingly, the data array is a mix of indexed elements and named elements

He gives an example of the output from the function and shows how, using data from the returned array, you can compare constants (IMAGETYPE_JPEG, IMAGETYPE_GIF, IMAGETYPE_PNG) to determine what the image type is. This is a better option than relying on the extension of the file as that can be easily faked.

Davey Shafik has posted a quick article to his site talking about class constants and something new he learned about them (and how it relates to the uniform variable syntax handling in PHP7).

Yesterday on Twitter there was a conversation started by Marco Pivetta regarding a particularly horrible bit of code he had spotted [that] creates a string using sprintf() by prefixing ::PARAMNAME with the result of calling get_class() on the $api variable, and then passes that string into constant() which will give you the value of a constant using it’s string name.

The conversation continued with comments from Elizabeth Smith about why this workaround was needed in the past. Davey also suggests that it won't work as expected if the input is an object and not a string but a test from Trevor Suarez proved that incorrect as well (it does work). He ends the post talking about PHP7 and showing how, thanks to the uniform variable syntax changes, this same kind of handling can be done in many other ways too.

Nikita Popov has posted the second part of a series looking at how PHP 7 represents values internally. In the first part of the series the focus was on the major change from PHP 5: the zval updates and how they're allocated. This new post gets into more of the details on each of the types and how they're handled.

In the first part of this article, high level changes in the internal value representation between PHP 5 and PHP 7 were discussed. As a reminder, the main difference was that zvals are no longer individually allocated and don’t store a reference count themselves. Simple values like integers or floats can be stored directly in a zval, while complex values are represented using a pointer to a separate structure.

[...] In the following the details of the individual complex types will be discussed and compared to the previous implementation in PHP 5. One of the complex types are references, which were already covered in the previous part. Another type that will not be covered here are resources, because I don’t consider them to be interesting.

He goes through a few of the different types including strings and arrays and then gets into detail on how objects have changed from PHP 5 to PHP7. He also talks about "indirect zvals" (the IS_INDIRECT handling) that points to another zval instance rather than embedding it. Finally, he talks about two other constants, IS_CONSTANT and IN_CONSTANT_AST, and how they're used behind the scenes with some example code to illustrate.

NetTuts.com has posted the second part of their "Refactoring Legacy Code" series today continuing on from their beginning of the series. They continue the refactor of their "trivia" application.

Old code. Ugly code. Complicated code. Spaghetti code. Jibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. We first met our legacy source code in our previous lesson. [...] The time for the first changes have come and what better way to understand a difficult code base than start to extract magic constants and strings into variables? These seemingly simple tasks will give us greater and sometimes unexpected insights into the inner workings of legacy code. We will need to figure out the intentions of the original code author and find the proper names for the pieces of code that we've never seen before.

They talk about refactoring out things like "magic strings" and other hard-coded return values and checks. They mention updating the tests to reflect these changes while keeping an eye out for "magic constants" as well.

The PHP.cc have posted another article in their series looking at the new features that come with the latest release of PHP (5.5). In this new post they cover the "CLASS" constant.

Last week, the first stable version of PHP 5.5 was released. It introduced a class-level constant, aptly named CLASS, that is automatically available on all classes and holds the fully-qualified name of that class. [...] So why would you need such a constant? [...] When you need the fully qualified name of a namespaced class that is referenced by a namespace alias ... then it gets interesting.

He illustrates with an example of a unit test using stubs and mocks. The normal method requires the definition of the class namespace in the "getMock" call. With the CLASS constant, PHP can extract that information from the namespace referenced in the "use" and drop it in as a replacement.

In a new post to his blog Lee Davis describes the enum conundrum - what's the right solution for effectively using ENUM-type fields in your data?

So a user signs up and I want to store a status that reflects their account, or at least an identifier representing that status. Their account could be active, disabled (temporarily), pending approval or maybe deleted. Should I use an enum? I’ve heard they’re evil. Maybe having a reference table with statuses would be better? But now I have to manage a separate table just for that one snippet of data, is that overkill? Could I maybe use that status table for other entities? Or, could I instead just use an integer and reference it on the code level? What is the right solution?

He presents three of the most common situations he's seen for people using enums in the application:

• "I used enums all over the place" (maintenance between code and DB values)
• "use a reference table"
• "I could use a class constant to represent the enum" (enforced in the app)

Of the three, he suggests the third as the option with the most advantages. Not only does it make it simpler to get the allowed values for the field, but you're also more flexible in the kinds of validation you can do on the values.