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 this new post on thePHP.cc site they talk about calling instance methods statically, more specifically that it should be avoided.

There are quite a few things in PHP 4 that were a bit strange. One example is that PHP 4 allowed static calling of instance methods. [...] To keep backwards compatibility with PHP 4, this code works up to PHP 5, even though [the method in the example[ is not declared static.

[...] Now things will get really weird. When calling an instance method of another class statically, the $this context would carry over from the caller to the called class. In other words, $this suddenly refers to another object instance. While in PHP 5, this used to be an E_STRICT error, PHP 7 will emit an E_DEPRECATED error.

They point out that, while this is definitely odd behavior that shouldn't exist, it hasn't been removed because of PHP's backwards compatibility principles and only removing functionality like this in major versions. So, instead, they recommend calling all non-static methods using an instance of the class injected rather than directly calling them.

The SitePoint PHP blog has a new tutorial posted by author Christopher Thomas showing you how, with the help of Twilio, create a Laravel-based application that lets users communicate with it via phone calls.

Twilio is a SaaS application which enables developers to build telephone applications using web technologies. In this two-part series, we will leverage Twilio to build a weather forecast app that is accessed using the telephone system. The backend will be written with the Laravel framework (an exploratory video course is available for purchase here, or in the form of written tutorials here).

In this part, we will create a simple program that will allow a user to call a phone number that we buy from Twilio, enter a zipcode, and receive the current weather forecast.

You'll need to have a Laravel project already set up and a development environment to work in as well as Composer installed versions of Guzzle and the Twilio SDK. With that all set up, he dives right into the code, setting up routes and creating the "Weather" service class. This class is what's used to interact with the Twilio API and respond to user prompts with weather data from the weather.gov API. Next up is the controller that provides the endpoints for Twilio to hit and return the weather data back to their waiting connection. A bit of middleware is set up to sent the Twilio request signature each time and instructions are included on how to test the local system with the public Twilio API (using Ngrok).

Toon Verwerft has a post on his site with details about a micro-optimization you can use in your PHP application by using fully-qualified function calls, specifying the namespace even for root level PHP functions.

Today, a little conversation on Twitter escalated rather quickly. Apparently PHP runs function calls differently depending on namespaced or non namespaced context. When calling functions in a namespaced context, additional actions are triggered in PHP which result in slower execution. In this article, I'll explain what happens and how you can speed up your application.

The conversation started with [this tweet]. To understand the difference between global and namespaced function calls better, I'll explain what is going on under the hood.

He starts with this "under the hood" functionality, showing an example of a user-defined, root level function and the opcodes that result. He compares this to the opcodes generated when a namespaced function is called and the extra checking that goes into it (including checking both the namespace and the root levels). Another tweet implied that, because of this difference in checking, fully-qualified function calls would result in a performance increase. He set out to prove it as fact and used the phpbench tool to run four tests with various namespaced and non-namespaced examples. He includes the code he used for the testing and the results from a sample execution. There is, in fact, a slight performance gain from the fully-qualified version. He finishes up the post with some suggestions on using this knowledge including the root-level namespacing for built-in PHP functions.

In a new post to his site Stoimen Popov makes the recommendation to not call the destructor explicitly in your code and provides some alternatives.

PHP 5 introduces a destructor concept similar to that of other object-oriented languages, such as C++” says the documentation for destructors. [...] Well, as you can not call the constructor explicitly [...] so we should not call the destructor explicitly. The problem is that I’ve seen this many times, but it’s a pity that this won’t destroy the object and it is still a valid PHP code.

He talks about __destruct and it's role in PHP's set of "magic methods" and what they exist to do. He then gets into a few examples of what code could look like that uses a destructor and the difference between normal handling calling the destructor explicitly. The main differences is that calling it explicitly does not destroy the object, it's basically like calling any other method. He does include an interesting method for destroying the object - setting it to null - and notes that the destructor fires then too. He also points out a few interesting things about cloning objects and how object references work when setting nulls as in the previous example.

Anna Filina has posted a quick hint around testing methods that make static methods calls to other parts of your application. Static method calls are notoriously difficult to test, especially with PHPUnit.

I had trouble testing a particularly painful codebase. It had static calls and implicit dependencies all over the place, to name just a few problems.

One of the things that it often did was to call static methods that would increment counters in the database and cache stuff. Example: Record::incrementViews() It was making things difficult. To avoid messing with the original codebase too much, I came up with this quick and dirty way to ignore those dependencies.

Her solution makes use of a mockStaticDependency method that then turns around and redefines the class in question (like her "Record" above) with a __callStatic through an eval. She points out that usually using eval is "evil" but in this case it made testing the functionality much simpler when no feedback was needed from the static method. In the comments on the post, someone also makes a recommendation of the Patchwork library for PHP that allows for "monkey patching" and modifying classes/functionality to redefine functions and methods in a similar way.

Julien Pauli has a new post today sharing an interesting function optimization he found using the Blackfire execution profiler.

This blog post is a technical explanation of a PHP optimization found with BlackFire profiler into a PHP script. The related post is located here : http://blog.blackfire.io/owncloud.html

He found that a replacement of a call to strlen with an isset optimized the script by about 20%. It's not typical though, he explains. He points out that the optimization worked so well because the call was part of a loop. He gets into some of the "under the covers" details of why this speed boost happens and even includes the op code output showing the difference. He then starts getting deep into the internal code for PHP and walks through each step made in the evaluation of a string's length. He finishes the post looking at isset (not technically a function) and how it handles its data checking. He also includes information about opcode caching and how to best maximize its impact.

Andrew Podner has a new post today looking at dynamic class method creation in PHP - aka "overloading" with the __call magic method.

What is overloading and what would I need it for? [...] In most languages, overloading just means you can have multiple methods with the same name, but they just had a different number/type of arguments. In PHP, it is a little different. Overloading in PHP means that you can actually create dynamic function names and the behavior will be dependent upon the function name that is used.

He gives an example through a sample application, first stating the requirements the business has for it then showing how to use the "__call" method to handle "getBy" requests made to a database class. It searches the database based on the field (ex. "getByusername" searches on "username") and he includes two examples of it in use. He also briefly touches on the use of the "__callStatic" magic method for handling static method calls similarly.

Marcelo Gornstein has returned to his "IVR with PHP" series in this latest post (see others here and here). In this new post he shows you how to create a full flow of interaction for your callers:

The last article was about how to create call flow nodes for asterisk, using pagi and php, to easily create telephony applications. It's now time to add a layer on top of it, and create a complete call flow with several nodes.

He talks about NodeControllers to control execution flow, results from their execution, available actions and an example of creating a controller and adding nodes. He builds on this simple controller and shows how to handle a few actions including responding to user feedback, adding multiple menu options and some more complex logic using a closure to contain the functionality.

Marcelo Gornstein has a new post to his blog (in his PHP and PAGI series) showing how you can use call nodes to create more complicated telephony applications.

Now, since version 1.10.0, PAGI comes with a neat feature, which is a small abstraction layer over the pagi client, called "Nodes". Also, the "NodeController" will orchestrate how those nodes interact with each other. Nodes are essentially call flow nodes. These new features will allow you to implement complete call flows in no time, and maybe even without using the pagi client by yourself. In this article, I'll introduce the nodes by themselves (and how to unit test them), and will talk about the node controller in a latter article.

He introduces the concepts of these Nodes and shows how to create a simple client, make a node off of it and read in the user's input. Code is also included for a basic IVR menu, working with pre-prompt messages, digits, datetimes and calling card PIN numbers. There's also some examples of calling validators on the input, making callbacks, tracking the nodes via in internal system and mocking out the nodes for testing purposes.