In this post to his site Tomas Votruba covers the create_function function, its deprecation in PHP 7.2 and how to refactor your code to remove it.

If there would be "Miss Deprecation of PHP 7.2", create_function() would definitely win. They can be very complex, tricky and very hard convert to PHP code. Moreover without tests.

Do you have over 5 create_function() pieces in your code? Let's see how to migrate them.

He starts by talking about why it's being deprecated (it's essentially an eval) and some examples of how it could be used to execute code. He then goes through several usage examples and shows how to refactor them into anonymous functions. In his examples he uses a mix of regular code conversions and a sort of hybrid using strings and code to replace the string (probably) used previously with create_function.

On thePHP.cc site today they have a quick post that looks ahead at the future of the PHP language towards PHP version 8 and one planned feature - the deprecation of some multi-byte character handling.

Since the attempt to create a Unicode-based PHP implementation has failed, PHP 7 – just like PHP 5 – does not handle Unicode strings natively. The commonly used UTF-8 encoding, for example, is a multibyte encoding, as opposed to ASCII, where each character is represented by one single byte.

[...] UTF-8 is a variable-length encoding and each character (code point, to be exact) is represented by one to four bytes. For ASCII characters, everything works smoothly, because UTF-8 is a superset of ASCII. The problems start with non-ASCII characters.

The post covers some of the common issues with multi-byte Unicode characters in PHP and the role that the iconv and mbstring functions play in their handling. It shows how the mbstring handling allows developers to "cheat a little" and where, when PHP 8 comes around, the main issue will lie: the deprecation of thembstring.func_overload setting in the php.ini.

On the Kinsta blog there's a new tutorial by Carlo Daniele with a look ahead at the next version of the PHP language - PHP 7.2 - and what you can expect.

Currently in RC3, PHP 7.2 is planned to be released on November 30. The new release is coming with new features, functions, and improvements that will allow us to write better code. In this post, I will introduce some of the most interesting language features coming with PHP 7.2.

You can see the full list of upcoming changes on the Requests For Comments page.

Their list covers a number of the updates coming in this version including:

• Argument type declarations [for objects]
• Parameter Type Widening
• Trailing commas in list syntax
• Several security improvements

They also cover some of the functionality that's being deprecated and what kind of impact this new version will have on WordPress users.

In a new post to his site Martin Hujer looks ahead at the next major release for the PHP language - PHP 7.2 - and what new features and changes are coming with it.

PHP 7.2 is planned to be released on 30th November 2017 (see the timetable). And it comes with two new security features in the core, several smaller improvements and some language legacy clean-ups. In the article, I will describe what the improvements and changes are. I read the RFCs, discussions on internals and PRs on Github, so you don't have to.

Among the changes he lists are updates like:

• Argon2 Password Hashing
• Make Libsodium a Core Extension
• Object typehint
• Counting of non-countable objects

He also lists out some of the things that will be deprecated in 7.2 including parse_str without a second argument, create_function, mbstring.func_overload and asset with a string argument. You can check out these and other other changes coming (along with code examples) in the full post.

On the Zend Developer Zone there's a new post sharing some of the deprecations coming with PHP 7.2, the next release in the 7.x series (planned release sometime later this year).

PHP is a living language and as such, as some things are added, others are removed. Since PHP adheres to the best practice of Semantic Versioning, nothing will be going away in PHP 7.2, but some things will be marked as “Deprecated” so that developers can start removing them from their code and finding better ways to get the job done.

PHP 7.2 brings us a new list of things that will be eventually going away. The complete list, as well as explinations and voting can be found at “PHP RFC: Deprecations for PHP 7.2”

They include a "hit list" of the functionality that will be affected including the removal of support for __autoload, the create_function function, removal of assert and the (unset) cast. The RFC has been moved to the "Accepted" state so now work will be done to make these and other deprecations happen in this next great release.

In this new post to the Laravel News site they list out some of the deprecations coming in PHP 7.2 based on this RFC.

The PHP 7.2 RFC for deprecating some current functionality has been approved. The following items are included in this list and will begin throwing deprecated notices.

The list of features to be deprecated includes:

• the magic __autoload function
• the create_function function
• the (unset) cast
• the each function

Most of the things in the list are functionality that you just don't see much in recent PHP development. It could cause problems for older codebases but for those already on PHp 7 it shouldn't take much to make the necessary changes.

In this article on Medium.com Amo Chohan covers some of the changes that are coming to the language in PHP 7.1.

Below are the key changes that will be introduced (or removed) in PHP 7.1. For a full list, and to see which changes are being discussed, check out the official PHP RFC.

Included in the list of updates/additions are things like:

• Catching multiple exception types
• Support class constant visibility
• Void return types
• Warn about invalid strings in arithmetic
• Deprecate and remove mcrypt()

He then goes through some of the complete list and provides a brief overview of the change and some code samples where appropriate.

In this post to his site Matthew Weier O'Phinney talks about a change in the Zend Framework ZendMVC package to deprecate the ServiceLocatorAware interface and some of the unexpected backlash of it.

A month or two ago, we pushed a new release of zend-mvc that provides a number of forwards-compatibility features to help users prepare their applications for the upcoming v3 release.

One of those was, evidently, quite controversial: in v3, zend-servicemanager no longer defines the ServiceLocatorAwareInterface, and this particular release of zend-mvc raises deprecation notices when you attempt to inject a service locator into application services, or pull a service locator within your controllers.

He shares some of the "constructive" feedback they received when they made the change, most importantly asking for a justification for the change. He then goes through their thinking behind the change, some of its original intent and how it allowed for "dependency hiding" in its use. He gets into some detailed code examples for this last point, some of the errors that could happen as a result and other issues (like no type safety and the brittleness of using a service locator).

On the Symfony blog there's a new post briefly looking at Symfony 3 and what's different about it as compared to previous releases (and what's not).

Symfony 3.0.0 was released on November 2015 as planned by the Symfony 3 roadmap. As we do with any new Symfony version, we should publish a blog series explaining its new features.

However, Symfony 3.0 is a very special version which contains no new features comparing it with Symfony 2.8. Their only difference is that 3.0 removed any feature marked as deprecated in 2.8. That's why we won't publish any "New in Symfony 3.0" post. Instead, let's do a quick recap of the new Symfony 2.8 features which are also available on Symfony 3.0.

Among the items on their list are things like:

• New components like Guard Authentication and LDAP
• A MicroKernel component
• Improvements for VarDumper, Console and the Security components

Each of the changes on their list include links to get more information about the component and the post wraps up with a quick "how-to" on upgrading to Symfony 3 from other releases.

On the Symfony blog there's a post talking about a tool they've introduced that is helping to "pave the way" for the upcoming version 3 release of the Symfony framework - the Deprecation Detector tool.

Symfony 3 will be released at the end of November 2015. Learning from our own history, the transition from Symfony 2 to 3 will be much more pleasant than the transition from symfony 1 to 2 that happened in July 2011.

Technically speaking, Symfony 3 includes no new features comparing it with Symfony 2.8, which will be released at the same time. [...] This means that your Symfony applications won't work on Symfony 3 unless you remove all their deprecations. In order to simplify the task of finding which deprecations affect your applications, a new tool called Deprecation Detector has just been released.

The tool runs static analysis against your codebase and finds locations where you're using deprecated methods/classes/interfaces/etc and reports them back for fixing. The post includes the commands you'll need to get the tool installed and how to run it against your code. You can find out more about the project and get details on command line options on its GitHub repository.