Modular Programming with PHP 7

Scalar type hints are not an entirely new feature in PHP. With the introduction of PHP 5.0 we were given the ability to type hint classes and interfaces. PHP 5.1 extended this by introducing array type hinting. Later on, with PHP 5.4, we were additionally given the ability to type hint callable. Finally, PHP 7 introduced scalar type hints. Extending the type hints to scalars makes this probably one of the most exciting features added to PHP 7.

The following scalar type hints are now available:

By default, PHP 7 works in weak type-checking mode, and will attempt to convert to the specified type without complaint. We can control this mode using the strict_typesdeclare() directive.

The declare(strict_types=1); directive must be the first statement in a file, or else it will generate a compiler error. It only affects the specific file it is used in, and does not affect other included files. The directive is entirely compile-time and cannot be controlled at runtime:

declare(strict_types=0); //weak type-checking
declare(strict_types=1); // strict type-checking

Let's assume the following simple function that accepts hinted scalar types.

function hint (int $A, float $B, string $C, bool $D)
{
    var_dump($A, $B, $C, $D);
}

The weak type-checking rules for the new scalar type declarations are mostly the same as those of extensions and built-in PHP functions. Because of this automated conversion we might unknowingly lose data when passing it into a function. One simple example is passing a float into a function that requires an int; in which case conversion would simply strip away decimals.

Assuming the weak type-checking is on, as by default, the following can be observed:

hint(2, 4.6, 'false', true); 
/* int(2) float(4.6) string(5) "false" bool(true) */

hint(2.4, 4, true, 8);
/* int(2) float(4) string(1) "1" bool(true) */

We can see that the first function call passes on parameters as they are hinted. The second function call does not pass the exact types of parameters but still the function manages to execute as parameters go through conversion.

Assuming the weak type-checking is off, by using the declare(strict_types=1); directive, the following can be observed:

hint(2.4, 4, true, 8);

Fatal error: Uncaught TypeError: Argument 1 passed to hint() must be of the type integer, float given, called in php7.php on line 16 and defined in php7.php:8 Stack trace: #0 php7.php(16): hint(2.4, 4, true, 8) #1 {main} thrown in php7.php on line 8

The function call broke on the first argument resulting in the \TypeError exception. The strict_types=1 directive does not allow any type juggling. The parameter has to be of the same type, as hinted by the function definition.

In addition to type hinting, we can also type hint the return values. All of the type hints that can be applied to function parameters can be applied to function return values. This also implies to the weak type-checking rules.

To add a return type hint, simply follow the parameter list with a colon and the return type, as shown in the following example:

function divide(int $A, int $B) : int
{
    return $A / $B;
}

The preceding function definition says that the divide function expects two parameters of the int type, and is supposed to return a parameter of the int type.

Assuming the weak type-checking is on, as by default, the following can be observed:

var_dump(divide(10, 2)); // int(5)
var_dump(divide(10, 3)); // int(3)

Though the actual result of divide(10, 3)should be a float, the return type hint triggers conversion into an integer.

Assuming the weak type-checking is off, by using the declare(strict_types=1); directive, the following can be observed:

int(5) 
Fatal error: Uncaught TypeError: Return value of divide() must be of the type integer, float returned in php7.php:10 Stack trace: #0php7.php(14): divide(10, 3) #1 {main} thrown in php7.php on line 10

With the strict_types=1 directive in place, the divide(10, 3) fails with the \TypeError exception.

With the addition of anonymous classes, PHP objects gained closure-like capabilities. We can now instantiate objects through nameless classes, which brings us closer to object literal syntax found in other languages. Let's take a look at the following simple example:

$object = new class {
    public function hello($message) {
        return "Hello $message";
    }
};

echo$object->hello('PHP');

The preceding example shows an $object variable storing a reference to an instance of an anonymous class. The more likely usage would be to directly pass the new class to a function parameter, without storing it as a variable, as shown here:

$helper->sayHello(new class {
    public function hello($message) {
        return "Hello $message";
    }
});

Similar to any normal class, anonymous classes can pass arguments through to their constructors, extend other classes, implement interfaces, and use traits:

class TheClass {}
interface TheInterface {}
trait TheTrait {}

$object = new class('A', 'B', 'C') extends TheClass implements TheInterface {

    use TheTrait;

    public $A;
    private $B;
    protected $C;

    public function __construct($A, $B, $C)
    {
        $this->A = $A;
        $this->B = $B;
        $this->C = $C;
    }
};

var_dump($object);

The above example would output:

object(class@anonymous)#1 (3) { ["A"]=> string(1) "A"["B":"class@anonymous":private]=> string(1) "B"["C":protected]=> string(1) "C" }

The internal name of an anonymous class is generated with a unique reference based on its address.

There is no definitive answer as to when to use anonymous classes. It depends almost entirely on the application we are building, and the objects, depending on their perspective and usage.

Some of the benefits of using anonymous classes are as follows:

Anonymous classes, or rather objects instantiated from anonymous classes, cannot be serialized. Trying to serialize them results in a fatal error as follows:

Fatal error: Uncaught Exception: Serialization of 'class@anonymous' is not allowed in php7.php:29 Stack trace: #0 php7.php(29): serialize(Object(class@anonymous)) #1 {main} thrown in php7.php on line 29

Nesting an anonymous class does not give it access to private or protected methods and properties of the outer class. In order to use the outer class protected methods and properties, the anonymous class can extend the outer class. Ignoring methods, private or protected properties of the outer class can be used in the anonymous class if passed through its constructor:

class Outer
{
    private $prop = 1;
    protected $prop2 = 2;

    protected function outerFunc1()
    {
        return 3;
    }

    public function outerFunc2()
    {
        return new class($this->prop) extends Outer
        {
            private $prop3;

            public function __construct($prop)
            {
                $this->prop3 = $prop;
            }

            public function innerFunc1()
            {
                return $this->prop2 + $this->prop3 + $this->outerFunc1();
            }
        };
    }
}

echo (new Outer)->outerFunc2()->innerFunc1(); //6

Though we labeled them as anonymous classes, they are not really anonymous in terms of the internal name the PHP engine assigns to objects instantiated from these classes. The internal name of an anonymous class is generated with a unique reference based on its address.

The statement get_class(new class{}); would result in something like class@anonymous/php7.php0x7f33c22381c8, where 0x7f33c22381c8 is the internal address. If we were to define the exact same anonymous class elsewhere in the code, its class name would be different as it would have a different memory address assigned. The resulting object in that case might have the same property values, which means they will be equal (==) but not identical (===).

PHP introduced the Closure class in the 5.3 version. Closure class is used to represent anonymous functions. Anonymous functions, implemented in PHP 5.3, yield objects of this type. As of PHP 5.4, the Closure class got several methods (bind, bindTo) that allow further control of the anonymous function after it has been created. These methods basically duplicate the Closure with a specific bound object and class scope. PHP 7 introduced the call method on a Closure class. The call method does not duplicate the closure, it temporarily binds the closure to new this ($newThis), and calls it with any given parameters. It then returns the return value of the closure.

The call function signature looks like the following:

function call ($newThis, ...$parameters) {}

$newThis is the object to bind the closure for the duration of the call. The parameters, which will be given as $parameters to the closure are optional, meaning zero or more.

Let's take a look at the following example of a simple Customer class and a $greeting closure:

class Customer {
    private $firstname;
    private $lastname;

    public function __construct($firstname, $lastname)
    {
        $this->firstname = $firstname;
        $this->lastname = $lastname;
    }
}

$customer = new Customer('John', 'Doe');

$greeting = function ($message) {
    return "$message $this->firstname $this->lastname!";
};

echo $greeting->call($customer, 'Hello');

Within the actual $greeting closure, there is no $this, it does not exist until the actual binding occurs. We could easily confirm this by directly calling a closure like $greeting('Hello');. However, we assume $this will come in to existence when we bind the closure to a given object instance via its call function. In which case, $this within the closure becomes $this of the customer object instance. The preceding example shows binding of $customer to the closure using a call method call. The resulting output displays Hello John Doe!

Generators provide a simple way to implement iterators without the overhead of implementing a class that implements the Iterator interface. They allow us to write code which uses foreach to iterate over a set of data without needing to build an array in memory. This eliminates the exceeds memory limit errors. They were not new to PHP, as they were added in PHP 5.5.

However, PHP 7 brings several new improvements to generators, one of which is generator delegation.

Generator delegation allows a generator to yield other generators, arrays, or objects that implement the Traversable interface. In another words, we might say that generator delegation is yielding subgenerators.

Let's take a look at the following example with three generator type functions:

function gen1() {
    yield '1';
    yield '2';
    yield '3';
}

function gen2() {
    yield '4';
    yield '5';
    yield '6';
}

function gen3() {
    yield '7';
    yield '8';
    yield from gen1();
    yield '9';
    yield from gen2();
    yield '10';
}

// output of the below code: 123
foreach (gen1() as $number) {
echo $number;
}

//output of the below code: 78123945610
foreach (gen3() as $number) {
    echo $number;
}

Yielding other generators requires using the yield from <expression> syntax.

Prior to PHP 7, generator functions were not able to return expressions. The inability of generator functions to specify return values limited their usefulness for multitasking in co-routine contexts.

PHP 7 made it possible for generators to return expressions. We can now call $generator->getReturn() to retrieve the return expression. Calling $generator->getReturn() when the generator has not yet returned, or has thrown an uncaught exception, will throw an exception.

If the generator has no return expression defined and has completed yielding, null is returned.

Let's take a look at the following example:

function gen() {
    yield 'A';
    yield 'B';
    yield 'C';

    return 'gen-return';
}

$generator = gen();

//output of the below code: object(Generator)#1 (0) { }
var_dump($generator);

// output of the below code: Fatal error
// var_dump($generator->getReturn());

// output of the below code: ABC
foreach ($generator as $letter) {
    echo $letter;
}

// string(10) "gen-return"
var_dump($generator->getReturn());

Looking at the gen() function definition and its return expression, one might expect the value of the $generator variable to be equal to the gen-return string. However, this is not the case, as the $generator variable becomes the instance of the \Generator class. Calling the getReturn() method on the generator while it is still open (not iterated over) will result in a fatal error.

If the code is structured in such a way that it is not obvious if the generator has been closed, we can use the valid method to check, before fetching the return value:

if ($generator->valid() === false) {
    var_dump($generator->getReturn());
}

In PHP 5 we had the ternary operator which tests a value and then returns the second element if that value is true, or third element if that value is false, as shown in the following code block:

$check = (5 > 3) ? 'Correct!' : 'Faulty!'; // Correct!
$check = (5 < 3) ? 'Correct!' : 'Faulty!'; // Faulty!

While processing user-provided data in web-centered languages such as PHP, it is common to check for variable existence. If a variable doesn't exist, then set it to some default value. A ternary operator makes this easy for us, as shown here:

$role = isset($_GET['role']) ? $_GET['role'] : 'guest';

However, easy is not always quick or elegant. With that in mind, PHP 7 set out to resolve one of the most common usage patterns, by introducing the null coalesce operator(??).

The null coalesce operator enables us to write even shorter expressions, as in the following code block:

$role = $_GET['role'] ??'guest';

The coalesce operator(??) is added right after the $_GET['role'] variable, which returns the result of its first operand if it exists and is not NULL, or else its second operand. This means the $_GET['role'] ?? 'guest' is completely safe and will not raise an E_NOTICE.

We can also nest the coalesce operator:

$A = null; // or not set
$B = 10;

echo $A ?? 20; // 20
echo $A ?? $B ?? 30; // 10

Reading from left to right, the first value which exists and is not null is the value that will be returned. The benefit of this construct is that it enables a clean and effective way to achieve safe fallback to the desired value.

The three-way comparison operator, also known as the Spaceship operator, was introduced in PHP 7. Its syntax goes as follows:

(expr) <=> (expr)

The operator returns 0 if both operands are equal, 1 if the left is greater, and -1 if the right is greater.

It uses the same comparison rules as other existing comparison operators: <, <=, ==, >=, and >:

operator<=> equivalent
$a < $b($a <=> $b) === -1
$a <= $b($a <=> $b) === -1 || ($a <=> $b) === 0
$a == $b($a <=> $b) === 0
$a != $b($a <=> $b) !== 0
$a >= $b($a <=> $b) === 1 || ($a <=> $b) === 0
$a > $b($a <=> $b) === 1

The following are some examples of Spaceship operator behavior:

// Floats
echo 1.5 <=> 1.5; // 0
echo 1.5 <=> 2.5; // -1
echo 2.5 <=> 1.5; // 1

// Strings
echo "a"<=>"a"; // 0
echo "a"<=>"b"; // -1
echo "b"<=>"a"; // 1

echo "a"<=>"aa"; // -1
echo "zz"<=>"aa"; // 1

// Arrays
echo [] <=> []; // 0
echo [1, 2, 3] <=> [1, 2, 3]; // 0
echo [1, 2, 3] <=> []; // 1
echo [1, 2, 3] <=> [1, 2, 1]; // 1
echo [1, 2, 3] <=> [1, 2, 4]; // -1

// Objects
$a = (object) ["a" =>"b"]; 
$b = (object) ["a" =>"b"]; 
echo $a <=> $b; // 0

$a = (object) ["a" =>"b"]; 
$b = (object) ["a" =>"c"]; 
echo $a <=> $b; // -1

$a = (object) ["a" =>"c"]; 
$b = (object) ["a" =>"b"]; 
echo $a <=> $b; // 1

// only values are compared
$a = (object) ["a" =>"b"]; 
$b = (object) ["b" =>"b"]; 
echo $a <=> $b; // 0

One practical use case for this operator is for writing callbacks used in sorting functions like usort, uasort, and uksort:

$letters = ['D', 'B', 'A', 'C', 'E'];

usort($letters, function($a, $b) {
return $a <=> $b;
});

var_dump($letters);

// array(5) { [0]=> string(1) "A" [1]=> string(1) "B" [2]=>string(1) "C" [3]=> string(1) "D" [4]=> string(1) "E" }

Though PHP 5 introduced the exception model, overall errors and error handling remained somewhat unpolished. Basically PHP had two error handling systems. Traditional errors still popped out and were not handled by try…catch blocks.

Take the following E_RECOVERABLE_ERROR as an example:

class Address
{
    private $customer;
    public function __construct(Customer $customer)
    {
        $this->customer = $customer;
    }
}

$customer = new stdClass();

try {
    $address = new Address($customer);
} catch (\Exception $e) {
    echo 'handling';
} finally {
echo 'cleanup';
}

The try…catch block has no effect here, as the error is not interpreted as an exception, rather a catchable fatal error:

Catchable fatal error: Argument 1 passed to Address::__construct() must be an instance of Customer, instance of stdClass given, called in script.php on line 15 and defined in script.php on line 6.

A possible workaround involves setting a user-defined error handler by using the set_error_handler function as follows:

set_error_handler(function($code, $message) {
    throw new \Exception($message, $code);
});

The error handler, as written above, would now transform every error into an exception, therefore making it catchable with try…catch blocks.

PHP 7 made fatal and catchable fatal errors part of engine exceptions, therefore catchable with try…catch blocks. This excludes warnings and notices which still do not pass through the exception system, which makes sense for backward compatibility reasons.

It also introduced a new exception hierarchy via the \Throwable interface. \Exception and \Error implement the \Throwable interface.

Standard PHP fatal and catchable fatal are now thrown as \Error exceptions, though they will continue to trigger traditional fatal error if they are uncaught.

Throughout our application we must use \Exception and \Error, as we cannot implement the \Throwable interface directly. We could, however, use the following block to catch all errors, regardless of whether it is the \Exception or \Error type:

try {
// statements
} catch (\Throwable $t) {
    // handling
} finally {
// cleanup
}

The ParseError is a nice PHP 7 addition to error handling. We can now handle parse errors triggered by eval(), include and require statements, as well as those thrown by \ParseError exceptions. It extends \Error, which in turn implements a \Throwable interface.

The following is an example of a broken PHP file, because of a missing "," inbetween between array items:

<?php

$config = [
'host' =>'localhost'
'user' =>'john'
];

return $config;

The following is an example of a file including config.php:

<?php 

try {
include 'config.php';
} catch (\ParseError $e) {
// handle broken file case
}

We can now safely catch possible parse errors.

The dirname function has been with us since PHP 4. It's probably one of the most often used functions in PHP. Up until PHP 7, this function only accepted the path parameter. With PHP 7, the new levels parameter was added.

Let's take a look at the following example:

// would echo '/var/www/html/app/etc'
echo dirname('/var/www/html/app/etc/config/');

// would echo '/var/www/html/app/etc'
echo dirname('/var/www/html/app/etc/config.php');

// would echo '/var/www/html/app'
echo dirname('/var/www/html/app/etc/config.php', 2);

// would echo '/var/www/html'
echo dirname('/var/www/html/app/etc/config.php', 3);

By assigning the levels value, we indicate how many levels to go up from the assigned path value. Though small, the addition of the levels parameter will certainly make it easier to write some of the code that deals with paths.

The intdiv is a new integer division function introduced in PHP 7. The function accepts dividend and divisor as parameters and returns the integer quotient of their division, as shown here by the function description:

int intdiv(int $dividend, int $divisor)

Let's take a look at the following few examples:

intdiv(5, 3); // int(1)
intdiv(-5, 3); // int(-1)
intdiv(5, -2); // int(-2)
intdiv(-5, -2); // int(2)
intdiv(PHP_INT_MAX, PHP_INT_MAX); // int(1)
intdiv(PHP_INT_MIN, PHP_INT_MIN); // int(1)

// following two throw error
intdiv(PHP_INT_MIN, -1); // ArithmeticError
intdiv(1, 0); // DivisionByZeroError

If the dividend is PHP_INT_MIN and the divisor is -1, then an ArithmeticError exception is thrown. If the divisor is 0, then the DivisionByZeroError exception is thrown.

Prior to PHP 7, constants defined with define() could only contain scalar expressions, but not arrays. As of PHP 5.6, it is possible to define an array constant by using const keywords, and as of PHP 7, array constants can also be defined using define():

// the define() example
define('FRAMEWORK', [
'version' => 1.2,
'licence' =>'enterprise'
]);

echo FRAMEWORK['version']; // 1.2
echo FRAMEWORK['licence']; // enterprise

// the class const example
class App {
    const FRAMEWORK = [
'version' => 1.2,
'licence' =>'enterprise'
    ];
}

echo App::FRAMEWORK['version']; // 1.2
echo App::FRAMEWORK['licence']; // enterprise

Constants may not be redefined or undefined once they have been set.

To make PHP's parser more complete for various variable dereferences, PHP 7 introduced a uniform variable syntax. With uniform variable syntax all variables are evaluated from left to right.

Unlike various functions, keywords, or settings being removed, changes in semantics like this one can be quite impacting for the existing code base. The following code demonstrates the syntax, its old meaning and new:

// Syntax
$$foo['bar']['baz']
// PHP 5.x:
// Using a multidimensional array value as variable name
${$foo['bar']['baz']}
// PHP 7:
// Accessing a multidimensional array within a variable-variable
($$foo)['bar']['baz']

// Syntax
$foo->$bar['baz']
// PHP 5.x:
// Using an array value as a property name
$foo->{$bar['baz']}
// PHP 7:
// Accessing an array within a variable-property
($foo->$bar)['baz']

// Syntax
$foo->$bar['baz']()
// PHP 5.x:
// Using an array value as a method name
$foo->{$bar['baz']}()
// PHP 7:
// Calling a closure within an array in a variable-property
($foo->$bar)['baz']()

// Syntax
Foo::$bar['baz']()
// PHP 5.x:
// Using an array value as a static method name
Foo::{$bar['baz']}()
// PHP 7:
// Calling a closure within an array in a static variable
(Foo::$bar)['baz']()

Aside from previously rewritten examples of old-to-new syntax, there are now a few newly supported syntax combinations.

PHP 7 now supports nested double colons,::, and following is an example of it:

// Access a static property on a string class name
// or object inside an array
$foo['bar']::$baz;
// Access a static property on a string class name or object
// returned by a static method call on a string class name
// or object
$foo::bar()::$baz;
// Call a static method on a string class or object returned by
// an instance method call
$foo->bar()::baz();

We can also nest methods and function calls—or any callables—by doubling up on parentheses as shown in the following code examples:

// Call a callable returned by a function
foo()();
// Call a callable returned by an instance method
$foo->bar()();
// Call a callable returned by a static method
Foo::bar()();
// Call a callable return another callable
$foo()();

Furthermore, we can now dereference any valid expression enclosed with parentheses:

// Access an array key
(expression)['foo'];
// Access a property
(expression)->foo;
// Call a method
(expression)->foo();
// Access a static property
(expression)::$foo;
// Call a static method
(expression)::foo();
// Call a callable
(expression)();
// Access a character
(expression){0};

PHP 7 introduced two new CSPRNG functions. CSPRNG is an acronym for cryptographically secure pseudo-random number generator.

The first, random_bytes, generates an arbitrary length string of cryptographic random bytes that are suitable for cryptographic use, such as when generating salts, keys, or initialization vectors. The function accepts only one (length) parameter, representing the length of the random string that should be returned in bytes. It returns a string containing the requested number of cryptographically secure random bytes, or, optionally, it throws an exception if an appropriate source of randomness cannot be found.

The following is an example of random_bytes usage:

$bytes = random_bytes(5);

The second, random_int, generates cryptographic random integers that are suitable for use where unbiased results are critical, such as when shuffling a deck of cards for a poker game. The function accepts two (min, max) parameters, representing the lowest value to be returned (must be PHP_INT_MIN or higher) and the highest value to be returned (must be less than or equal to PHP_INT_MAX). It returns a cryptographically secure random integer in the range min to max (inclusive).

The following is an example of random_int usage:

$int = random_int(1, 10);
$int = random_int(PHP_INT_MIN, 500);
$int = random_int(20, PHP_INT_MAX);
$int = random_int(PHP_INT_MIN, PHP_INT_MAX);

Serialized data can include objects. These objects can further include functions like destructors, __toString, and __call. In order to increase security when unserializing objects on unstructured data, PHP 7 introduced the optional options parameter to the existing unserialize function.

The options parameter is of type array that currently only accepts the allowed_classes key.

The allowed_classes can have one of three values:

The following is an example of using the allowed_classes option:

class Customer{
    public function __construct(){
        echo '__construct';
    }

    public function __destruct(){
        echo '__destruct';
    }

    public function __toString(){
        echo '__toString';
        return '__toString';
    }

    public function __call($name, $arguments) {
        echo '__call';
    }
}

$customer = new Customer();

$s = serialize($customer); // triggers: __construct, __destruct

$u = unserialize($s); // triggers: __destruct
echo get_class($u); // Customer

$u = unserialize($s, ['allowed_classes'=>false]); // does not trigger anything
echo get_class($u); // __PHP_Incomplete_Class

We can see that the object of that class which is not accepted is instantiated as __PHP_Incomplete_Class.

According to the http://php.net/manual/en/reserved.keywords.php list, PHP has over 60 reserved keywords. These make up for language constructs, like names for properties, methods, constants within classes, interfaces, and traits.

Sometimes these reserved words end up clashing with user defined API declarations.

To resolve the issue, PHP 7.0 introduced the context sensitive lexer. With the context sensitive lexer, we may now use keywords for property, function, and constant names within our code.

The following are a few practical examples related to the impact of context sensitive lexer:

class ReportPool {
    public function include(Report $report) {
//
    }
}

$reportPool = new ReportPool();
$reportPool->include(new Report());

class Collection extends \ArrayAccess, \Countable, \IteratorAggregate {

    public function forEach(callable $callback) {
//
    }

    public function list() {
//
    }

    public static function new(array $items) {
        return new self($items);
    }
}

Collection::new(['var1', 'var2'])
->forEach(function($index, $item){ /* ... */ })
->list();

The only exception being the class keyword, which remains reserved in class constant context, as shown here:

class Customer {
  const class = 'Retail'; // Fatal error
}

The group use declarations are introduced in PHP 7 as a way to cut verbosities when importing multiple classes from a common namespace. They enable shorthand syntax as follows:

use Library\Group1\Group2\{ ClassA, ClassB, ClassC as Classy };

Let's take a look at the following examples where class names within the same namespace are group used:

// Current use syntax
use Doctrine\Common\Collections\Expr\Comparison;
use Doctrine\Common\Collections\Expr\Value;
use Doctrine\Common\Collections\Expr\CompositeExpression;

// Group use syntax
use Doctrine\Common\Collections\Expr\{ Comparison, Value, CompositeExpression };

We can also use the group use declarations on part of namespaces, as shown in the following example:

// Current use syntax
use Symfony\Component\Console\Helper\Table;
use Symfony\Component\Console\Input\ArrayInput;
use Symfony\Component\Console\Output\NullOutput;
use Symfony\Component\Console\Question\Question;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\Question\ChoiceQuestion as Choice;
use Symfony\Component\Console\Question\ConfirmationQuestion;

// Group use syntax
use Symfony\Component\Console\{
  Helper\Table,
  Input\ArrayInput,
  Input\InputInterface,
  Output\NullOutput,
  Output\OutputInterface,
  Question\Question,
  Question\ChoiceQuestion as Choice,
  Question\ConfirmationQuestion,
};

We can further use group use for importing functions and constants as shown in the following lines of code:

use Framework\Component\{
SubComponent\ClassA,
function OtherComponent\someFunction,
const OtherComponent\SOME_CONSTANT
};

Unicode, and UTF-8 in particular, have grown increasingly popular in PHP applications.

PHP 7 adds the new escape sequence for double-quoted strings and heredocs, with the syntax as follows:

\u{code-point}

It produces the UTF-8 encoding of a Unicode code point, specified with hexadecimal digits. It is worth noting that the length of the code-point within curly braces is arbitrary. This means that we can use \u{FF} or the more traditional \u{00FF}.

The following is a simple listing of the four most traded currencies, their symbols, and their UTF-8 code points:

Euro€U+20AC
Japanese Yen¥U+00A5
Pound sterling£U+00A3
Australian dollar$U+0024

Some of these symbols usually exist directly on a keyboard, so it's easy to write them down as shown here:

echo "the € currency";
echo "the ¥ currency";
echo "the £ currency";
echo "the $ currency";

However, the majority of other symbols are not as easily accessible via the keyboard as single keystrokes, and therefore need to be written in the form of code-points, shown as follows:

echo "the \u{1F632} face";
echo "the \u{1F609} face";
echo "the \u{1F60F} face";

In older versions of PHP, the resulting output of preceding statements would be the following:

the \u{1F632} face
the \u{1F609} face
the \u{1F60F} face

This obviously did not parse code-points, as it was outputting them literally.

PHP 7 introduced Unicode code-point escape sequence syntax to string literals, making previous statements result in the following output:

the 😉 face
the 😉 face
the 😉 face

Assertions is a debug feature, used to check the given assertion and take appropriate action if its result is false. They have been part of PHP for years, ever since PHP 4.

Assertions differ from error handling in a way that assertions cover for impossible cases, whereas errors are possible and need to be handled.

Using assertions as a general-purpose error handling mechanism should be avoided. Assertions do not allow for recovery from errors. Assertion failure will normally halt the execution of a program.

With modern debugging tools like Xdebug, not many developers use assertions for debugging.

Assertions can be easily enabled and disabled using the assert_options function or the assert.active INI setting.

To use assertions, we pass in either an expression or a string as shown in the following function signature:

// PHP 5
bool assert ( mixed $assertion [, string $description ] )

// PHP 7
bool assert ( mixed $assertion [, Throwable $exception ] )

These two signatures differ in the second parameter. PHP 7 can accept either string $description or $exception.

If the expression result or the result of evaluating the string evaluates to false, then a warning is raised. If the second parameter is passed as $exception, then an exception will be thrown instead of failure.

In regards to php.ini configuration options, the assert function has been expanded to allow for so-called zero-cost assertions:

zend.assertions = 1 // Enable
zend.assertions = 0 // Disable
zend.assertions = -1 // Zero-cost

With zero-cost settings, assertions have zero impact on performance and execution as they are not compiled.

Finally, the Boolean assert.exception option was added to the INI setting. Setting it to true, results in AssertionError exceptions for the failed assertions.

In PHP 5, list() assigns the values starting with the right-most parameter. In PHP 7, list() starts with the left-most parameter. Basically, values are now assigned to variables in the order they are defined.

However, this only affects the case where list() is being used in conjunction with the array [] operator, as discussed in the following code block:

<?php

list($color1, $color2, $color3) = ['green', 'yellow', 'blue'];
var_dump($color1, $color2, $color3);

list($colors[], $colors[], $colors[]) = ['green', 'yellow', 'blue'];
var_dump($colors);

Output of the preceding code in PHP 5 would result in the following:

string(5) "green"
string(6) "yellow"
string(4) "blue"

array(3) { 
[0]=> string(5) "blue"
[1]=> string(6) "yellow"
[2]=> string(4) "green"
}

Output of the preceding code in PHP 7 would result in the following:

string(5) "green"
string(6) "yellow"
string(4) "blue"

array(3) { 
[0]=> string(5) "green"
[1]=> string(6) "yellow"
[2]=> string(4) "blue"
}

The order of assignment might change again in the future, so we should not rely heavily on it.

Prior to PHP 7, the session_start() function did not directly accept any configuration options. Any configuration options we wanted to set on the session, needed to come from php.ini:

// PHP 5
ini_set('session.name', 'THEAPP');
ini_set('session.cookie_lifetime', 3600);
ini_set('session.cookie_httponly', 1);
session_start();

// PHP 7
session_start([
'name' =>'THEAPP',
'cookie_lifetime' => 3600,
'cookie_httponly' => 1
]);

Driven by the goal of performance optimization, a new lazy_write runtime configuration was added in PHP 7. When lazy_write is set to 1, the session data is only rewritten if it changes. This is the default behavior:

session_start([
'name' =>'THEAPP',
'cookie_lifetime' => 3600,
'cookie_httponly' => 1,
'lazy_write' => 1
]);

While changes listed here might not look impressive at first, being able to override session options directly via the session_start function gives certain flexibility to our code.

Globally accepted, major versions of software have the luxury of breaking backward compatibility. Ideally, not much, but in order to keep the software moving forward, some old ideas need to be left behind. These changes don't come overnight. Certain features are first flagged as deprecated to warn developers that it will be removed in future versions of the language. Sometimes this period of deprecation takes years.

Throughout PHP 5.x, a number of features have been marked as deprecated, and in PHP 7.0, they have all been removed.

The POSIX-compatible regular expressions have been deprecated in PHP 5.3, and now completely removed in PHP 7.

The following functions are no longer available for use:

We should instead use Perl Compatible Regular Expressions (PCRE). The http://php.net/manual/en/book.pcre.php is a great source of documentation for these functions.

The mysql extension, which had been deprecated in PHP 5.5, has now been removed. None of the mysql_* functions are available anymore. We should instead use the mysqli extension. The good thing is that moving from mysql to mysqli functions is mostly simple, as when adding i to our code, the mysql_* function calls and passes the database handle (returned by mysqli_connect) as the first parameter. The http://php.net/manual/en/book.mysqli.php is a great source of documentation for these functions.

The PHP script and ASP tags are no longer available:

<!-- PHP script tag example -->
<script language="php">
// Code here
</script>

<!-- PHP ASP tag example -->
<%
// Code here
%>
<%=$varToEcho; %>

Application frameworks are a collection of functions, classes, configurations, and conventions all designed to support the development of web applications, services, and APIs. Some applications are embracing an API first approach, whereas server-side REST and SOAP APIs are built via PHP, and client side in other technologies like JavaScript.

When building a web application, we usually have three obvious choices:

In a nutshell, frameworks are here to make it easier and quicker for us to build our software. A great deal of programming languages out there have popular frameworks. PHP is no exception to this.

Given the popularity of PHP as a go-to web programming language, it is no surprise that dozens of frameworks have sprouted over the years. Choosing the "right" framework is a daunting task, even so more for fresh starters. What is right for one project or a team might not be right for another.

However, there are some general, high level segments each modern framework should encompass. These account for:

While it's perfectly alright to code an entire web application in pure PHP without using any framework, the majority of today's projects do use frameworks.

The benefits of using frameworks outweigh the purity of doing it all from scratch. Frameworks are usually well supported and documented, which makes it easier for teams to catch up with libraries, project structure, conventions, and other things.

When it comes to PHP frameworks, it is worth pointing out a few popular ones:

This is by no means a complete or even a popularity sorted list.