PHP 8 new features and changes - Part 3

This is part 3 of the blog. Here we will continue our discussions on the other features and changes in PHP 8.

Stringable interface

The new Stringable interface which is introduced in PHP 8 is now automatically added to all the classes which implement the __toString method.

`PhpToken` Tokenizer class

The new PhpToken class which is introduced in PHP 8, provides an object-oriented approach to tokenizer results.

The return value is an array of PhpToken objects.

abstract methods

Previously, PHP would not allow us to declare a private abstract function in any PHP version. That has now changed with PHP 8. It allows us to declare a method as abstract even if a method with the same name exists in the parent class.

For example:

class ParentFoo {
    private function demo() {}
}

abstract class ChildFoo extends ParentFoo{
    abstract protected function demo();
}

Before PHP 8, the above would produce the following error:

Fatal error: Cannot make non-abstract method Foo::test() abstract in class ChildFoo in ... on line ...

Variable syntax tweaks

From the RFC: "the Uniform Variable Syntax RFC resolved several inconsistencies in PHP's variable syntax. This RFC intends to address a small handful of cases that were overlooked."

ext-json is now always available

Previously compiling PHP without the JSON extension enabled was allowed but that is not the case anymore. This is a healthy change in PHP 8. 

If the composer.json file already has PHP 8 in the required parameter then the ext-JSON is no longer required to be manually added.

{
   "require": {  
       "php": "^8.0",  
-       "ext-json": "*",  
   }
 }

Concatenation takes precedence

A line of code such as this:

echo "sum: " . $a + $b;

Would be previously interpreted like this:

echo ("sum: " . $a) + $b;

And in PHP 8, it is interpreted like this:

echo "sum: " . ($a + $b);

Reliable numeric strings

From the RFC, “all strings which currently emit the E_NOTICE “A non-well formed numeric value encountered” will be reclassified into the E_WARNING “A non-numeric value encountered” except if the leading-numeric string contained only trailing whitespace. And the various cases which currently emit an E_WARNING will be promoted to TypeErrors.”

Reliable string to number comparisons

From the RFC, “0 == "foobar" returns true. This RFC proposes to make non-strict comparisons more useful and less error-prone, by using a number comparison only if the string is numeric. Otherwise, the number is converted into a string, and a string comparison is performed. ”