Tomas Vortuba has put together a post sharing a summary of what's new in PHP 7.3 using a bit different tactic than just descriptions: via diffs (in about 30 seconds).

No time but eager to hear PHP news? PHP 7.3 is out in December 2018 and it brings 173 changes. Which are the most useful ones?

For each item in his list he provides code snippets showing the change for:

• Comma After the Last Argument
• First and Last Array Key
• Countable for Risky Variables
• Safer JSON Parsing

Each item on the list also links over to the related RFC for the feature that provides more detail on the change.

In a post in the Laravel News site, they quickly cover one of the many changes coming with the next jump in versions of the PHP language (v7.3): trailing commas in function calls.

Well PHP 7.3 won’t have arrow functions (that would be dreamy). However, trailing commas in function calls is an excellent addition coming to PHP 7.3.

In PHP 7.3, trailing commas in function calls will be valid syntax. That is to say, you can use trailing commas when calling functions, but not defining them.

They then include two places where these trailing commas could be useful: in the use of variadic functions and in PHP array definitions. The remainder of the post shows the concept of "trailing commas" in other languages including Javascript, Python, and Haskell. The first alpha release of PHP 7.3 has been released if you'd like to try this out with your own code.

In a post to his site Matthieu Napoli shares some of his thoughts about "code style rationality" including code formatting in general and some suggestions on one of the harder things in development - naming things.

Habits are sometimes making us blind. We think X looks prettier than Y but that’s just the habit speaking. In this article I’ll try to take a rational approach at coding style. That means leaving the “it looks ugly/better” at the door.

If at any point you feel like something “just doesn’t look good”, breath in, breath out, and try it! Nothing beats hands-on experience, not even some random article on the internet.

He looks at a few subjects specifically (there's way too many to cover them all in detail):

• the use of trailing commas
• alignment of values in docblock comments
• keeping docblock comments minimal
• using the "Interface" suffix
• using the "Exception" suffix

He ends the post by reminding readers that the point is to think about code style logically and that no rules are written in stone.

Internationalizing a website can bring all sorts of challenges, as Markus Wolff found out when working on a recent project:

When you're building international websites, there's always something new to learn. Especially if one of the languages your website is available in uses a character set different from anything you're used to. For jimdo.com, the greatest challenge as of yet is the chinese version.

His focus isn't so much on the content of the page but on one small character that caused him headaches - the comma. Unfortunately, it seems that Unicode has its own commas that don't quite adhere to the "normal" rules to make them easy to work with (and, in his case, split with a regular expression). The fix to the situation was simple, though - adding a "u" modifier after the expression made it Unicode-aware and split the information correctly.

Internationalizing a website can bring all sorts of challenges, as Markus Wolff found out when working on a recent project:

When you're building international websites, there's always something new to learn. Especially if one of the languages your website is available in uses a character set different from anything you're used to. For jimdo.com, the greatest challenge as of yet is the chinese version.

His focus isn't so much on the content of the page but on one small character that caused him headaches - the comma. Unfortunately, it seems that Unicode has its own commas that don't quite adhere to the "normal" rules to make them easy to work with (and, in his case, split with a regular expression). The fix to the situation was simple, though - adding a "u" modifier after the expression made it Unicode-aware and split the information correctly.

Sara Golemon, inspired by an IRC discussion has gathered together some of her thoughts on "using PHP's string interpolation without using an optimizer".

She explains how a simple string (an echo statement) is interpreted into a simple compilation structure. Her next step, though (placing a variable inside a string) yields something that seems more complex than it should be. A concatination example simplifies things down a bit, but, oddly enough, it gets even better when a comma is used instead of a period to concatinate. She also gives an example of a heredoc statement that doesn't conform to the interpolation standards you'd think.

Why does this happen? Because there are about a dozen ways that a variable can be hidden inside an interpolated string. Similarly, when looking for a heredoc end-token, the token can be an arbitrary length, containing any of the label characters, and may or may not sit on a line by itself. Put simply, it's too difficult to encompass in one regular expression.

She specifically mentions the APC caching system and its built-in optimizer to help with some of these issues. It pulls the interpolations back down to a size they should be and anticipating operations by pre-resolving things like constants and scalar expressions.

Of course, not everyone can install this pacakge, so she suggests an alternative:

You can still avoid 90% of the INIT_STRING/ADD_STRING dilema by simply using single quotes and concatenation (or commas when dealing with echo statements). It's a simple trick and one which shouldn't harm maintainability too much, but on a large, complicated script, you just might see an extra request or two per second.

Sara Golemon, inspired by an IRC discussion has gathered together some of her thoughts on "using PHP's string interpolation without using an optimizer".

She explains how a simple string (an echo statement) is interpreted into a simple compilation structure. Her next step, though (placing a variable inside a string) yields something that seems more complex than it should be. A concatination example simplifies things down a bit, but, oddly enough, it gets even better when a comma is used instead of a period to concatinate. She also gives an example of a heredoc statement that doesn't conform to the interpolation standards you'd think.

Why does this happen? Because there are about a dozen ways that a variable can be hidden inside an interpolated string. Similarly, when looking for a heredoc end-token, the token can be an arbitrary length, containing any of the label characters, and may or may not sit on a line by itself. Put simply, it's too difficult to encompass in one regular expression.

She specifically mentions the APC caching system and its built-in optimizer to help with some of these issues. It pulls the interpolations back down to a size they should be and anticipating operations by pre-resolving things like constants and scalar expressions.

Of course, not everyone can install this pacakge, so she suggests an alternative:

You can still avoid 90% of the INIT_STRING/ADD_STRING dilema by simply using single quotes and concatenation (or commas when dealing with echo statements). It's a simple trick and one which shouldn't harm maintainability too much, but on a large, complicated script, you just might see an extra request or two per second.