Upgrading to PHP 7

Alternative PHP Tags

While some developers may not even be aware of it, PHP has alternative open and close tags, both of which have been removed.

These were known as script tags, as shown in Example 2-1, and ASP tags—which included a short echo tag—as shown in Example 2-2.

<script language="php">
    // Code here
</script>

<%
    // Code here
%>

<%=$varToEcho; %>

While I expect that the number of people using these tags is minimal, I have seen the ASP syntax used for templates. If you are using them, you will need to change to using the standard PHP tags, <?php, <?=, and ?>.

POSIX-Compatible Regular Expressions

Deprecated in PHP 5.3, POSIX-compatible regular expressions, used for string pattern matching, have been removed in PHP 7.0. This means that the entire ext/ereg extension has been removed.

This includes the following functions:

• ereg()

• eregi()

• ereg_replace()

• eregi_replace()

• split()

• spliti()

• sql_regcase()

$url = "https://example.org/path/here";

// POSIX
$matches = [];
$regex = "^(http(s?))://(.*)$";
if (eregi($regex, $url, $matches)) { 
    // string matched
    var_dump($matches);
    /*
    array(5) {
      [0] =>
      string(29) "https://example.org/path/here"
      [1] =>
      string(5) "https"
      [2] =>
      string(1) "s"
      [3] =>
      string(21) "example.org/path/here"
    }
    */
}

// PCRE
$matches = [];
$regex = "@^(http(s?))://(.*)$@i";  
if (preg_match($regex, $url, $matches)) {
    // string matched
    var_dump($matches);
    /*
    the resulting array is the same as with eregi above
    */
}

$url = "https://example.org/path/here?foo=bar";

$matches = [];
$regex = "@         # Delimiter
^                   # Begining of the string
(?<protocol>        # Name the submatch: protocol
    http            # Match the http protocol
    (?:             # Ignore the subgroup used for https matching
        s?          # Optionally match the s in the https protocol
    )
)
://                 # Match the :// from the protocol
(?<host>            # Name the submatch: host
    .*              # Match any characters
    ?               # But don't be greedy.
                    # This will stop at the first '/'.
)
(?<path>            # Name the submatch: path
    /               # Match the /
    [^\?]+          # Match any character that isn't a ?
)
?                   # but only if the path exists
(?:                 # Ignore the subgroup for the ?
    \?              # Match the query string delimiter
    (?<query>       # Name the submatch: query
        .+          # Match the query string itself
    )
)
?                   # but only if it exists
$                   # End of string
@ix";               # Use the i (case-insentive)
                    # and x (extended) flags 

if (preg_match($regex, $url, $matches)) {
    // string matched
    var_dump($matches);
    /*
    array(9) {
      [0] =>
      string(37) "https://example.org/path/here?foo=bar"
      'protocol' => 
      string(5) "https" 
      [1] =>
      string(5) "https"
      'host' =>
      string(11) "example.org"
      [2] =>
      string(11) "example.org"
      'path' =>
      string(10) "/path/here"
      [3] =>
      string(10) "/path/here"
      'query' =>
      string(7) "foo=bar"
      [4] =>
      string(7) "foo=bar"
    }
    */
}

Multiple Default Cases in Switches

When creating the PHP language spec, a bug was found: you could define multiple default: cases inside a switch, but only the last one would execute, which could lead to potential—hard to find—bugs, as shown in Example 2-5.

switch ($expr) {
    default:
         echo "Hello World";
         break;
    default: 
         echo "Goodbye Moon!";
         break;
}

To solve this, the ability to define this was removed, and now PHP 7 will throw a fatal error if you try to do so:

Fatal error: Switch statements may only contain one default clause

Summary

While this isn’t every backward-incompatible change, it is what will likely trip you up when migrating to PHP 7.0.

Moving away from these deprecated features may not be quick or easy, but doing so will bring more performance, enhanced security, and better code to your projects.

If you aren’t using any of these deprecated features, your transition to PHP 7 will largely be painless, so congratulations!

Consistency Fixes

With uniform variable syntax all variables are evaluated from left to right.

This is primarily only an issue when constructing complex dynamic variables and properties. As you can see in Example 3-1 we are moving from the inconsistent PHP 5.x behavior to a new left to right consistent behavior. Also, as shown in Example 3-1, you can achieve the same PHP 5.x behavior in PHP 7, or the new PHP 7 behavior in PHP 5.x by explicitly specifying the order of operations with the addition of appropriate parentheses () and braces {}.

// Syntax
$$var['key1']['key2'];
// PHP 5.x:
// Using a multidimensional array value as variable name
${$var['key1']['key2']};
// PHP 7:
// Accessing a multidimensional array within a variable-variable
($$var)['key1']['key2'];

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


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

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

New Syntax

One of the primary benefits of uniform variable syntax, other than consistency, is that it enables many new combinations of syntax—including some that are not yet supported by the language but that are no longer blocked by a parser that can’t handle the syntax.

// Call a closure inside an array returned by another closure
$foo()['bar']();

// Call a property by dereferencing an array literal
[$obj1, $obj2][0]->prop;

// Access a character by index in a returned string
getStr(){0};

// 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();

$foo = 'Foo';
$class = 'CLASS';
$constant = 'BAR';

echo $foo::$class::$constant;
echo $foo::{$class}::$constant;
echo $foo::{"$class"}::$constant;
echo $foo::{"$class"}::{"$constant"};
echo $foo::CLASS::$constant;
echo $foo::CLASS::{"$constant"};
echo $foo::($class)::($constant);

// 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()();

// 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};

// Define and immediately call a closure without assignment
(function() { /* ... */ })();

// Call a callable within an object property
($obj->callable)();

Dereferencing scalars

PHP 7 also has some new dereferencing for scalars, in particular the ability to call methods using array-notation callables, as well as the less than useful ability to use scalar strings as class names. Some examples can be seen in Example 3-8.

// Call a dynamic static method
["className", "staticMethod"]();

// Call a dynamic instance method
[$object, "method"]();

// Use a string scalar as a class name
'className'::staticMethod();

Future Syntax

Additionally, as noted previously, the addition of universal variable syntax also allows us to look forward at new possibilities for the language. The one possibility that most people are excited about is the prospect of object scalars—that is, the ability to call methods that act directly upon a scalar value. While they are not yet possible in PHP 7.0, some examples of potential syntax can be seen in Example 3-9.

// Object scalars — method calls on scalar values
"string"->toLower();

Backward Compatibility Issues

There was one casualty that will now be a parse error, rather than just interpreted differently, and that is when you mix variable-variables and the global keyword. With PHP 7, global will now only take unambiguous variables. You can see the old unsupported syntax and the unambiguous alternative in Example 3-10.

global $$foo->bar; // Now a parse error

// instead make sure to add braces to make it unambiguous
global ${$foo->bar};

Summary

While Uniform Variable Syntax finally brings some much needed consistency to PHP—even if we didn’t know it!—it also introduces what are probably the hardest bugs to detect when upgrading to PHP.

Thankfully, it mostly affects variable-variables and other more complex variable syntax that have long been considered poor practice and are rarely used.

Operators

PHP 7.0 adds two new operators, the null coalesce operator and the combined comparison operator.

$foo = isset($bar) ? $bar : $baz;

$foo = $bar ?? $baz;

$config =   $config ??
            $this->config ??
            static::$defaultConfig; 

// Pre Spacefaring^W PHP 7
function order_func_traditional($a, $b) {
    return ($a < $b) ? -1 : (($a > $b) ? 1 : 0);
}

// Post PHP 7
function order_func_spaceship($a, $b) {
    return $a <=> $b;
}

Constant Arrays

Up until now, constants defined with define() could only contain scalar values. With PHP 7.0, they have been updated to match constants defined by const, allowing you to set them to constant arrays. Example 4-4 demonstrates this new capability.

define('FOO', [
    'bar' => 'baz',
    'bat' => 'qux'
]);

echo FOO['bar']; 

Unpacking Objects Using list()

The list construct will now allow you to unpack objects that implement the \ArrayAccess interface, allowing you to use them just like arrays, as shown in Example 4-5.

$object = new \ArrayObject(json_decode($json)); 
list($foo, $bar, $baz) = $object;

New Functions

Several new functions have been added with this release.

intdiv(8, 3); 

Regular Expressions

As shown in Deprecated Features, ext/ereg has been removed, but this isn’t the only change to regular expressions in PHP 7.0.

This release adds a new preg_replace_callback_array() function that makes it much nicer to perform a number of regular expression replacements with different callbacks for each. As shown in Example 4-7, you pass in an array with regular expressions for keys, and closures—or other callables—that accept an array of matches. All matches will be replaced with the return value from the callable.

$header = "X-Custom-Header: foo\nbar";

$normalizedHeader = preg_replace_callback_array(
    [
        "/(.*?):/" => function($matches) {
            return strtolower($matches[0]);
        },
        "/\s+/" => function($matches) {
            return "-";
        }
    ],
    $header
); 

The other change to the PCRE functions is the removal of the /e modifier used with preg_replace(). This modifier allowed you to use code that would be evaluated against matches to create the replacement value. You should use preg_replace_callback() or the new preg_replace_callback_array() instead.

Cryptographically Secure Values

Traditionally, we’ve resorted to either very poor sources of randomness or openssl to generate cryptographically secure integers or strings.

PHP 7.0 adds two new simple functions, random_bytes() and random_int() to solve this problem in a platform-independent way.

As you might expect from the name, random_int() will return a random integer from a range, while random_bytes() will return a random string of a given length as shown in Example 4-8.

random_bytes(16); 
random_int(0, 10000); 

Function Changes

There have also been a few changes to existing functions.

session_start([
    'use_strict' => true,
    'lazy_write' => false
]);

Filtered unserialize()

In an attempt to enhance security, it is now possible to filter which classes will be instantiated when unserializing using unserialize().

This is done by adding a second argument that takes an array of options, of which there is currently only one, allowed_classes.

You can pass in one of three values for the allowed_classes option:

• false will instantiate all objects as __PHP_Incomplete_Class object instead.

• An array of class names will instantiate those as-is and return __PHP_Incomplete_Class for any others.

• true will result in the same behavior we’ve always had, and all objects will be instantiated they are.

Move Up Multiple Levels with dirname()

The dirname() function can now accept a second parameter to set how many levels up it will go, meaning you can avoid nesting as shown in Example 4-10.

$path = '/foo/bar/bat/baz';
dirname($path, 2); 

Salts Deprecated in password_hash()

The salt option for password_hash() has been deprecated, and it will now emit an E_DEPRECATED when used.

Summary

While these changes are small, they all add up to a nicer developer experience, and make the language more consistent.

Expectations

With PHP 7, assert() has been expanded by the Expectations RFC, allowing for so-called zero-cost assertions.

With this change, you not only disable assertions, but you can also remove all overhead entirely. With this setting, assertions are not compiled, regardless of string or expression arguments, and therefore have zero impact on performance/execution. This is different than just disabling assertions, which will still result in expressions being evaluated (potentially affecting execution) and will just skip the call.

This is done by changing the zend.assertions INI setting, as shown in Example 5-2.

zend.assertions  = 1  
zend.assertions  = 0  
zend.assertions  = -1 

Additionally, you can now have assertions throw an exception instead of a warning when the assertion fails. Again, this is an INI setting. Simply set assert.exceptions to 1 to throw exceptions or 0 (the default) to emit backward-compatible warnings instead.

The final change is the addition of a second argument, which allows you to specify a custom error message—as shown in Example 5-3—or an instance of an Exception.

assert(
    '$user instanceof \MyProject\User',
    'user was not a User object'
);

When you specify this custom message, it is shown instead of the expression on failure:

Warning: assert(): user was not a User object failed in <file> on line <num>

If you enable exceptions, the custom message will be used as the exception message, or if you specify an instance of an Exception, it will be thrown instead on failure.

Summary

With the addition of zero-cost assertions, you finally have a lightweight way to add sanity checking to your code during development, without impacting production.

While assertions are not for everybody, they can be a first step on the road to adding unit testing to your application.

Exceptions on Constructor Failure

Prior to PHP 7.0, if an internal class failed to instantiate properly, either a null or an unusable object was returned.

With PHP 7.0, all internal classes will throw an exception on __construct() failure. The type of exception will differ on the object being instantiated and the reason for failure—as shown in Example 6-1. If you pass in an argument of the incorrect type, a \TypeError is thrown (see \TypeError).

try {
    new MessageFormatter('en_US', null);
} catch (\IntlException $e) {
    
}

Engine Exceptions

With PHP 7.0, almost all fatal errors and catchable fatal errors are now engine exceptions. This is possible because an uncaught exception still results in a traditional fatal error, ensuring that the change is mostly backward compatible.

With this change, we get a number of benefits, the most obvious of which is that we can now handle fatal errors in our code using try… catch blocks. However, there are a number of other benefits:

• finally blocks are called.

• Object destructors (__destruct()) are called.

• Callbacks registered with register_shutdown_function() are called.

• Catchable-fatal errors are much easier to handle.

• As with all exceptions, it will have a stack trace, making it easier to debug.

\Throwable 
├── \Exception (implements \Throwable) 
│   ├── \LogicException
│   │   ├── \BadFunctionCallException
│   │   │   └── \BadMethodCallException
│   │   ├── \DomainException
│   │   ├── \InvalidArgumentException
│   │   ├── \LengthException
│   │   └── \OutOfRangeException
│   └── \RuntimeException
│       ├── \OutOfBoundsException
│       ├── \OverflowException
│       ├── \RangeException
│       ├── \UnderflowException
│       └── \UnexpectedValueException
└── \Error (implements \Throwable) 
    ├── \AssertionError
    ├── \ArithmeticError
    ├── \DivisionByZeroError
    ├── \ParseError
    └── \TypeError

Error Exceptions

As you can see in the exception hierarchy, there are four new error exceptions, each one used for a different purpose.

try {
    non_existent_function();
} catch (\Error $e) {
    // handle error
}

try {
    ini_set('assert.exception', 1);
    assert('true === false', 'Assertion failed');
} catch (\AssertionError $e) {
    
}

try {
    1 >> -1;
} catch (\ArithmeticError $e) {
    
}

try {
    10 % 0;
} catch (\DivisionByZeroError $e) {
    
}

try {
    include 'parse-error.php'; 
} catch (\ParseError $e) {
    
}

function example(callable $callback)
{
    return $callback();
}

try {
    example(new stdClass);
} catch (\TypeError $e) {
    
}

Catchable Fatal Errors

Another important change in PHP 7.0 is with catchable fatal errors. Previously, these could have been caught and handled using set_error_handler(). However, with PHP 7.0, they are now \Error exceptions, which, because an uncaught exception is still a real fatal error, will no longer be catchable in set_error_handler().

This is a backward-compatible break and means that to work in both PHP 5.x and 7, you need to use both set_error_handler() and a try…catch block.

\Throwable and Userland

With \Throwable and the new exception hierarchy, it would make sense that we could create our own branches in the exception hierarchy for completely custom exceptions by simply implementing the \Throwable interface.

Unfortunately, due to the fact that exceptions are magical under the hood, to be able to do things like capture line/file and stack trace information, you must still extend either \Exception or \Error, and cannot directly implement \Throwable alone.

Trying to implement \Throwable as shown in Example 6-9 will result in a fatal error.

Fatal error: Class MyException cannot implement
interface Throwable, extend Exception or Error instead

However, this is not the full story. You can extend \Throwable and then—while still extending \Error or \Exception—you can implement your extended interface, as shown in Example 6-10.

namespace My\Library;
interface MyExceptionInteface extends \Throwable {
  public function someMethod();

  public function someOtherMethod();
}

use \My\Library\MyExceptionInteface;
class MyException
    extends \Exception implements MyExceptionInterface
{
    // implement interface methods
}

Calling Methods on non-objects

Prior to PHP 7.0, if you were to attempt to call a method on a variable that did not contain an object, it would fatal error, with the message Call to a member function method() on a non-object.

It was initially decided that this should be a catchable fatal error; however, the addition of engine exceptions supersedes this, and it will now throw an \Error exception, which can be handled using try…catch.

Summary

While these changes will have a large impact on how you write your code—allowing you to gracefully handle almost all previously fatal errors—it has been implemented in an almost complete backward-compatible way.

In fact, if you are not using set_error_handler() to handle catchable fatal errors, you should not need to make any changes at all to your applications.

Unicode Codepoint Escape Syntax

A simple, yet powerful change allows us to easily embed complex Unicode characters in (double quoted) strings. Similar to other languages, this uses the \u escape sequence; however, in other languages, this is then followed directly by four hexadecimal digits to represent the character. For PHP 7.0, we instead follow it with an arbitrary number of hexadecimal numbers inside curly braces ({}).

The reason for this is that using a fixed length of four hexadecimal digits would limit us to the Basic Multilingual Plane, or BMP (U+0000 to U+FFFF), while many useful characters—in particular, emojis—reside outside of the BMP and require six hexadecimal digits.

Requiring six digits would mean that the majority of characters used would need to be left padded with two zeros (e.g., \u001000). Allowing arbitrary lengths would introduce potential ambiguity for Unicode points followed by other numbers, particularly if you were expecting the same behavior as the other languages with four digits.

With the curly braces, you can specify any number of hexadecimal digits, without the need to left pad, and you can completely avoid ambiguity.

This means that you can use \u{FF} or the more traditional \u{00FF}. We can also express those non-BNP characters such as “🐢” with \u{1F422}.

New Internationalization Features

Most Internationalization (I18N) features reside in the ext/intl extension, which has a new addition in PHP 7.0. The IntlChar class.

Working with Unicode Characters

The new IntlChar class provides a number of static methods that provide access to information about Unicode characters.

To retrieve a character name, you use the new IntlChar::charName() method, passing in the Unicode character, as shown in Example 7-1.

IntlChar::charName("\u{1F422}"); 

You can also use it to detect the type of character you are dealing with, for example, digits or punctuation.

$char = "\u{F1}"; 
IntlChar::isAlpha($char); 
IntlChar::isAlnum($char); 
IntlChar::isPunct($char); 

Summary

These changes bring a few of the new Unicode features to PHP 7.0, but this chapter barely scratches the surface of what they provide. However as you can see, the future of Unicode in PHP is alive and well.

Bind Closure On Call

With the addition of $this, Closure gained two methods, the instance method Closure->bindTo() and the static method Closure::bind().

Both of these functions do the same thing, but the first is called on the closure instance itself, while the static version must be passed the closure itself as the first argument. They both then take two arguments: the first is an object that $this will then point to, and the second is the scope from which to access $this.

This second one is important, because it means that you can change the scope to that of another class allowing you to call its private and protected methods and properties.

Both of the functions will then return a clone of the closure with the new $this and scope, rather than modifying the original.

The “Closure::call” RFC gives us an easier way to achieve the most common case, without needing to clone the object.

With PHP 7.0, the Closure class has a new instance method, Closure->call(), which takes an object as its first argument, to which $this is bound, and to which the scope is set, and then it calls the closure passing through any additional arguments passed to Closure->call(), as shown in Example 8-1.

class HelloWorld {
    private $greeting = "Hello";
}

$closure = function($whom) {
    echo $this->greeting . ' ' . $whom;
};

$obj = new HelloWorld();
$closure->call($obj, 'World');

In the previous example, the closure echos a nonexistent $this-⁠>​greeting property.

To resolve this, we call the closure using Closure->call() passing in an instance of the HelloWorld object. This changes $this to be that instance, and the calling scope to the HelloWorld class, allowing access to the private $this->greeting property.

Summary

This small but powerful change makes working with closures both much more convenient and more dangerous. Proceed with caution!

Generator Return Values

In PHP 5.5, if a generator function has a return statement followed by an expression (e.g., return true;), it would result in a parse error.

With the “Generator Return Expressions” RFC, this has now changed. As with the Closure class between 5.3 and 5.4, the Generator class that provides the magic for generators has moved from an implementation detail to a concrete implementation with the addition of the Generator->getReturn() method.

Not only will it no longer cause a parse error, but the Generator-⁠>​getReturn() method will allow you to retrieve the value returned by any return statement inside the generator. Example 9-1 shows this new functionality.

function helloGoodbye() {
    yield "Hello";
    yield " ";
    yield "World!";

    return "Goodbye Moon!";
}

$gen = helloGoodbye();

foreach ($gen as $value) {
    echo $value; 
}

echo $gen->getReturn(); 

Generator Delegation

While generator return values are neat, generator delegation is by far the more exciting of the enhancements being made.

Generator delegation allows a generator to yield other generators, objects that implement the \Traversable interface, and arrays, and they will be iterated on in turn. These are also known as sub-generators.

This is done using the new yield from <thing to iterate> syntax, and has the effect of flattening the subgenerators, so that the iterating mechanism has no knowledge of the delegation.

function hello() {
     yield "Hello";
     yield " ";
     yield "World!";

     yield from goodbye(); 
}

function goodbye() {
     yield "Goodbye";
     yield " ";
     yield "Moon!";
}

$gen = hello();
foreach ($gen as $value) {
     echo $value; 
}

If you wanted to, you could have further yield or yield from statements after the initial delegation, and any generator that you delegate to can, in turn, delegate, and the structure will be flattened again.

Summary

Despite these additions, generators still manage to be a lightweight alternative to Iterators. If you haven’t started using generators yet, now is a great time to start looking into them.

Context-Sensitive Lexer

PHP 7.0 introduces the context-sensitive lexer, which allows for the use of keywords as names for properties, methods, and constants within classes, interfaces, and traits.

What this means is that PHP goes from having 64 reserved keywords to having just one—class—and only in the class constant context.

You may now use any of the following keywords as property, function, and constant names:

The only exception is that you still cannot use const class, because it clashes with the fully qualified class name magic constant added in PHP 5.5.

PHP 4 Constructors Deprecated

While some called for them to be removed, the old PHP 4 constructors have instead been marked as deprecated in PHP 7.0.

Because removing PHP 4 constructors would be a backward-compatible break, any potential removal would happen no earlier than PHP 8.0, meaning this will probably not affect most people much for quite a while.

As a refresher, PHP 4 constructors have the same name as the class in which they are defined. Meaning a class foo has a PHP 4 constructor named foo().

The ability to use PHP 4 constructors was disallowed inside of namespaced classes when namespaces were introduced (PHP 5.3).

Group Use Declarations

In an effort to reduce duplication and simplify your code, the “Group Use Declarations” RFC was one of the more polarizing changes that managed to squeak in—passing with just 67 percent of the vote that required a two-thirds majority.

Group use declarations allow us to deduplicate the common prefixes in our use statements and just specify the unique parts within a block ({}) instead.

The way that you group statements is up to you. As you can see, Example 10-1 can be written differently, as shown in Example 10-2.

// Original
use Framework\Component\ClassA;
use Framework\Component\ClassB as ClassC;
use Framework\OtherComponent\ClassD;

// With group use statements
use Framework\{
     Component\ClassA,
     Component\ClassB as ClassC,
     OtherComponent\ClassD
};

use Framework\Component\{
     Component\ClassA,
     Component\ClassB as ClassC
};
Use Framework\OtherComponent\ClassD;

Also, if you want to import functions or constants—a feature that was added in PHP 5.6—you simply prefix the import line with function or const, respectively, as shown in Example 10-3.

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

Anonymous Classes

The addition of anonymous classes gives us closure-like capabilities, but for objects—with all the associated methods and properties that go along with that.

Anonymous classes are probably as close as we will get to an object literal syntax in PHP.

To create an anonymous class, you simple combine the new class($constructor, $args) followed by a standard class definition. An anonymous class is always instantiated during creation, giving you an object of that class.

Example 10-4 shows a simple example of creating an anonymous class.

$object = new class("bar") {
    public $foo;

    public function __construct($arg)
    {
        $this->foo = $arg;
    }
};

object(class@anonymous)#1 (1) {
  ["foo"]=>
  string(3) "bar"
}

Anonymous classes can be namespaced, and they support inheritance, traits, and interfaces, using the same syntax as regular classes, as shown in Example 10-5.

namespace MyProject\Component;

$object = new class ($args) extends Foo implements Bar {
	use Bat;
};

Anonymous Class Names

It may seem silly to think about “anonymous” classes having names, but internally every single one has a unique name, which is based on the memory address of the operation that created it.

These look something like class@0x7fa77f271bd0.

This is important because if you were to create a class within a loop, the instruction has the same memory address each iteration and therefore only one class is defined—but many instances of it are created.

This means that if the resulting object of two iterations have the same property values, they will be equal (== but not identical ===).

However, even if you define another anonymous class with exactly the same structure somewhere else in the code, it will have a different name based on its memory address and therefore not be equal. Example 10-6 demonstrates this behavior.

$objects = [];
foreach (["foo", "foo", "bar"] as $value) {
        $objects[] = new class($value) {

            public $value;

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

$objects[] = new class("foo") {

    public $value;

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

In Example 10-6, we create three instances of an anonymous class inside a foreach loop. The first two are passed foo as their constructor, while the third is passed bar.

We then create a fourth new anonymous class with the same definition and again pass in foo to the constructor.

Because of this, the first and second objects—$objects[0] and $objects[1], respectively—are equal, but not identical. However, neither of these two objects is equal to the third object—$objects[2].

They also will not be equal to the fourth object—$objects[3]—because it was defined outside of the loop and, despite its identical structure and value, it is a different class with a different name.

Summary

While the focus in PHP 7 is not sweeping changes to the object model, the changes that have been added are not insubstantial—in particular, anonymous classes opens up a number of new architecture possiblities.

These changes will hopefully make for more robust, easier to write, object-oriented code.

Scalar Type Hints

Alongside the introduction of a robust object model in PHP 5.0, we also got the first type hints: class/interface hints. The ability to require a function/method parameter was an instanceof a given class or interface.

PHP 5.1 introduced the array type hint, while PHP 5.4 added callable—the ability to type hint on anything that was a valid callback (e.g., closures, function names, etc.).

PHP 7.0 adds the ability to hint on scalar types:

• bool: Boolean values (i.e., true/false)

• float: Floating point numbers (e.g., 4.35)

• int: Integer numbers (e.g., 123)

• string: Strings (e.g., foo)

Example 11-1 shows each of these new hints in use.

function hinted(bool $a, float $b, int $c, string $c)
{

}

hinted(true, 4.35, 123, "foo");

function sendHttpStatus(int $statusCode, string $message)
{
    header('HTTP/1.0 ' .$statusCode. ' ' .$message);
}


sendHttpStatus(404, "File Not Found"); 
sendHttpStatus("403", "OK");
 

function add(int $a, int $b)
{
    return $a + $b;
}

add(897.23481, 361.53); 

// Enable strict types
declare(strict_types=1);
namespace MyProject\Component;

hinted("foo", 123, 4.35, true); 

Return Type Hints

In addition to more types of hints being available for arguments, we can now also type hint return values, using all the same types we can use for arguments.

Return hints follow the same rules under coercive or strict type hint settings. With coercive type hints, the return will be coerced to the hinted type when possible, while strict type hints will result in a \TypeError exception on type mismatch.

To add a type hint, simple follow the argument list with a colon and the return type, as shown in Example 11-5.

function divide(int $a, int $b): int
{
    return $a / $b;
}

divide(4, 2); 
divide(5, 2); 

In the preceding example, we have added an int return type hint to the divide() function that accepts two int arguments.

Despite the fact that all arguments are integers, because division can result in a float, you again may see precision loss in coercive mode or \TypeError exceptions in strict mode.

Reserved Keywords for Future Types

One final change that was added for type hinting is that the following list of type names can no longer be used as class, interface, or trait names:

• int

• float

• bool

• string

• true

• false

• null

This was done to facilitate potential future changes that would otherwise need to wait until PHP 8 to preserve backward compatiblity in PHP 7.x.

Summary

Unlike other languages where it is all or nothing when it comes to strict type hinting, PHP not only has opt-in strict hints, but it is up to the calling code, rather than the defining code.

This behavior is probably the only way to do scalar type hints “the PHP way.”

Regardless of this, you should still be able to reap the full benefits of type hinting: more reliable code, and the ability to do things like statically analyze it to ensure correctness.

However, there are still several features that some feel are missing from the current type hinting, namely nullable types (which would include null return types), compound types (e.g., int|float or predefined ones like numeric), a special void return type hint, and custom types. While none of these are yet slated for inclusion in future releases, there are many people working on most of them, so it could happen in PHP 7.1 and beyond.

Further Reading

• PHP Manual: Migrating from PHP 5.6.x to PHP 7.0.x

• Blog post: “What to Expect When You’re Expecting: PHP7, Part 1”

• Blog post: “What to Expect When You’re Expecting: PHP 7, Part 2”

• Blog post: “An Exceptional Change in PHP 7.0”

Other Resources

• Rasmus Lerdorf’s PHP 7 Dev Vagrant Box

• Jan Burkl’s PHP 7 Docker container (nightly builds)

• GoPHP7-ext, helping to migrate extensions to PHP 7

Deprecated Features

See: Deprecated Features

• “Removal of dead or not yet PHP7 ported SAPIs and extensions”

• “Make defining multiple default cases in a switch a syntax error”

• “Remove alternative PHP tags”

Uniform Variable Syntax

See: Uniform Variable Syntax

• “Uniform Variable Syntax”

Error Handling

See: Error Handling

• “Constructor behaviour of internal classes”

• “Throwable Interface”

• “Exceptions in the engine (for PHP 7)”

• “Catchable ‘call to a member function of a non-object’” (superseded by Exceptions in the engine)

Unicode Enhancements

See: Unicode Enhancements

• “Unicode Codepoint Escape Syntax”

• “ICU IntlChar class”

Generators

See: Generator Enhancements

• “Generator Return Expressions”

• “Generator Delegation”

Object-Oriented Programming

See: Changes in Object-Oriented Programming

• “Context Sensitive Lexer”

• “Remove PHP 4 Constructors”

• “Group Use Declarations”

• “Anonymous Classes”

Type Hints

See: Type Hints

• “Scalar Type Declarations”

• “Return Type Declarations”

• “Reserve More Types in PHP 7”