PHP has made it to the next major version (7.0) after 11 years, which took two years in development, and was released on December 3rd, 2015. Although this is a considerable amount of time in, there's a reason behind that. PHP has jumped from the major version five to seven. That was because PHP team started developing version six back in 2005 with a specific goal in mind; native support Unicode throughout the language, which will require modifying every bit of PHP code.

This was a huge commitment that the team couldn't keep up with, regardless of the vast amount of features which have been released. The development was abandoned after five years. However, there were features scheduled for a release of PHP 6 that are not related to Unicode, and those were published in PHP 5.3 and PHP 5.4.After PHP 6 goals couldn't be achieved, and to avoid confusion, the team voted to skip PHP 6 and take PHP 7 as the next major release.

Removed Features

PHP 7 comes with a lot of nice features. However, it also removes some features from the previous versions. Those features have been deprecated in PHP 5 (and earlier), and most likely developers have been avoiding using them due to that. The following features have been removed completely.

  • Regular Expressions with ereg

The ereg_* functions have been completely removed, and preg_* should be used instead.

  • Database Extensions: mysql, mssql, and sybase_ct

All mysql_* and mssql_* functions will no longer be available. These functions actually must not be used, mostly for security reasons. mysqli_* functions serve better, and the object-oriented version; PDO is more preferable.

  • Some of the Server Application Programming Interfaces (SAPIs)

Some of those SAPIs are apache, apache_hooks, continuity, phttpd and thttpd. The complete list could be found here.

  • Removal of date.timezone Warnings

Time zone warnings have been removed. Previously, date or time function was used, PHP will check if date.timezone was set in the php.ini file, and if it weren't, it would give a warning, even though it defaults to UTC.

  • Removal of Alternative PHP Tags

ASP style tags (long and short) with its directive in php.ini file, and the <script>.

Notice that the "short-open" tags have not been removed, so the following are the tags that remain (including the regular one at the beginning which is the one that you should be using).

<!--?php echo 'Hello World! Regular'; ?-->
<? echo 'Hello World! Short-open'; ?>
<!--?= 'Hello World! Short-open direct echo'; ?-->
  • Some Functions
    • mcrypt_generic_end
    • mcrypt_ecb
    • mcrypt_cbc
    • mcrypt_cfb
    • mcrypt_ofb
    • set_socket_blocking

Deprecated Features

The following features should be avoided, as they will likely be removed in the next major (or minor) PHP versions.

  • PHP 4 style constructors

Previously in PHP 4, the constructors were written as methods that have the same name as the class that they have been defined in. This way of writing a constructor has been deprecated, and instead, and the magic method __construct() should be used.

// This has been deprecated
class foo {
    function foo()
    {
        echo 'I am a constructor in PHP 4 Style';
    }
}

// You should use this instead
class bar {
    function __construct()
    {
        echo 'I am a constructor in PHP 5 Style';
    }
}
  • Static calls to non-static methods

This makes a lot of sense. In the prior PHP versions, developers were able to call non-static methods statically, which is a bad practice. Here's an example.

class foo {
    function bar()
    {
        echo 'I am not static, but I will still be called!';
    }
}

foo::bar();
  • Function password_hash() Salt Option

"The salt option for the password_hash() function has been deprecated to prevent developers from generating their own (usually insecure) salts. The function itself generates a cryptographically secure salt when no salt is provided by the developer - therefore custom salt generation should not be needed."

Scalar type declarations

Now that the removed and deprecated features have been introduced, let's take a look at the first new feature in PHP 7. Scalar type declarations, which is also known as type hinting, covers declaring a data type for function arguments. Some of these types are integer, string, boolean, array...etc. However, some of the valid types came before PHP 7 like class/interface name, array, callable, and self.

Scalar type declarations come in two flavours or techniques, coercive (default) and strict. Now, which one to choose does depend on your style of coding, but most likely Java or C++ developers would prefer the strict mode.

Let's compare those modes and see what the difference between them is and what is the difference while not using any.

function sum ($first, $second)
{
    echo 'First type: '.gettype($first);
    echo 'Second type: '.gettype($second);
    $total = $first + $second;
    echo 'Total type: '.gettype($total);
}

In the example above, the function sum takes two arguments; $first and $second. Our interest is the type of argument, not the value. Therefore, the code will print only the type.

Let's call that function, and see how it used to work without any mode, just to understand how both modes work, and compare the output.

sum(1, 2);
// First type: integer
// Second type: integer
// Total type: integer

That is typical, and there is not much to say. Arguments are integer, and the total is integer.

sum('1', '2');
// First type: string
// Second type: string
// Total type: integer

PHP took the strings and turned them into integers, and that's because it's flexible enough to know that I'm doing an addition.

Let's take a look at the coercive mode, and all we have to do is to modify the sum function like so.

function sum (int $first, int $second)
{
    echo 'First type: '.gettype($first);
    echo 'Second type: '.gettype($second);
    $total = $first + $second;
    echo 'Total type: '.gettype($total);
}

All we had to do is placing a declaration in front of each argument, telling PHP that we are expecting this type of argument.

sum(1, 2);
// First type: integer
// Second type: integer
// Total type: integer

So we passed integers, just exactly what the function expects them to be.

sum('1', '2');
// First type: integer
// Second type: integer
// Total type: integer

However, notice how the function changed the types of the arguments. PHP has coerced those string arguments into integer arguments immediately, as soon as the function execution starts.

The strict mode is a bit different, and to see how it works, we'll add declare(strict_types=1); to the top of my PHP file.

declare(strict_types=1);

function sum (int $first, int $second)
{
    echo 'First type: '.gettype($first);
    echo 'Second type: '.gettype($second);
    $total = $first + $second;
    echo 'Total type: '.gettype($total);
}

The "strictness" of typing for scalars is configured on a per-file basis.

The only difference between coercive and strict is, as foreseen from above, the declare(strict_types=1);. As the name suggests, PHP will act strictly upon the types now.

sum(1, 2);
// First type: integer
// Second type: integer
// Total type: integer

Again, when the type of the arguments have been given as it should be, PHP will continue to serve it as expected.

sum('1', '2');
// TypeError: Argument must be of type integer, string given

When tried passing arguments as string type, instead of returning any value, PHP throws a TypeError. This is how strict it becomes.

Return type declarations

Similar to scalar type declarations, the return type declarations specify the type of the value that will be returned from a function. The same types are available for return type declarations as are available for argument type declarations, and the two modes (coercive, and strict) that are available, apply here as well.

Let's go directly to the examples to see how can we use this. The examples will follow the same way of scalar type declarations.

function sum($first, $second)
{
    return $first + $second;
}

Well, the function says it all, we are not returning any types there, only returning the value. Let the function be called with integer values and check the type of the result with gettype().

echo gettype(sum(1, 2));
echo gettype(sum('1', '2'));
echo gettype(sum(1.0, 2.0));
//integer
//integer
//double

As expected, the type of summing integers is an integer. Summing strings that are convertibles to integers is an integer as well. However, float/double values could not be converted. Nothing new here, it's the same old PHP playing its same old behavior.

Now let's see how we can declare the type that we want to return in a coercive declaration mode.

function sum($first, $second): int
{
    return $first + $second;
}

After the sum function has been defined, right after the declaration of the arguments, we add a colon, then space, then an identifier (i.e. int, boolean, string, array..., etc.), and that's it. So how will that affect the output?

echo gettype(sum(1, 2));
echo gettype(sum('1', '2'));
echo gettype(sum(1.0, 2.0));
//integer
//integer
//integer

The first two are already integers as we saw before how PHP detect and convert strings that are convertibles to integers. However, instead of getting back double when passing float values, we get an integer. PHP has coerced that double value into an integer before it returns it from the function.

The way that we use the strict mode is by adding declare(strict_types=1), exactly as the scalar type declaration.

declare(strict_types=1);

function sum($first, $second): int
{
    return $first + $second;
}

Now let's see how that will affect the output.

echo gettype(sum(1, 2));
echo gettype(sum('1', '2'));
echo gettype(sum(1.0, 2.0));
//integer
//integer
//TypeError: Return value must be of the type integer, float returned

The first and second types were the same as before, but now in the third call, when passing in the floats, the type is not matching anymore. PHP starts complaining, TypeError: Return value must be of the type integer, float returned.