PHP 8.4 is here!

PHP 8.4 was officially released on November 21st, and with it comes a number of improvements and new features that you can - as of today - begin working with on your Upsun and Platform.sh projects.

How to upgrade

You can explore all that PHP 8.4 has to offer on your projects today.

php -r 'echo PHP_VERSION;'

upsun branch php-84-testing

composer upgrade

applications:
  your_application:
    type: "php:8.4"

name: "your_application"
type: "php:8.4"

applications:
  your_application:
    stack:
      - "php@8.4"

name: "your_application"
stack:
  - "php@8.4"

And test the changes on the new environment with an upsun push. Once the environment is live, you can merge the upgrades now (upsun merge), then come back to visit many of the performance improvements and new features packaged in the release below. You can test the changes on the new environment with an upsun push. You can as always find more information about available extensions and PHP configuration in the Upsun and Platform.sh documentation.

What’s changed in PHP 8.4?

With this release comes a number of resources to better understand what’s changed, and how those changes impact your applications:

• A comprehensive list of all changes can be found in the ChangeLog
• A side-by-side comparison on the release homepage
• Migrating from PHP 8.3.x to PHP 8.4.x instructions, which further breaks down the changes into:
  • New features
  • New classes, Enums, and interfaces
  • New functions
  • New global constants
  • Backward incompatible changes
  • Deprecated features
  • Removed extensions

New features

While there are a great number of improvements, updates, and added functions and subclasses in this release, much of the discussion up to this point has seemed to focus primarily on three enhancements in particular.

1. Property hooks

   With much inspiration from Kotlin, Property hooks in PHP 8.4 allow for defining additional logic (such as validation) associated with an objects get/set operations.

   From php.net:

   Object properties may now have additional logic associated with their get and set operations. Depending on the usage, that may or may not make the property virtual, that is, it has no backing value at all.

   <?php
   class Person
   {
       // A "virtual" property.  It may not be set explicitly.
       public string $fullName {
           get => $this->firstName . ' ' . $this->lastName;
       }
   
       // All write operations go through this hook, and the result is what is written.
       // Read access happens normally.
       public string $firstName {
           set => ucfirst(strtolower($value));
       }
   
       // All write operations go through this hook, which has to write to the backing value itself.
       // Read access happens normally.
       public string $lastName {
           set {
               if (strlen($value) < 2) {
                   throw new \InvalidArgumentException('Too short');
               }
               $this->lastName = $value;
           }
       }
   }
   
   $p = new Person();
   
   $p->firstName = 'peter';
   print $p->firstName; // Prints "Peter"
   $p->lastName = 'Peterson';
   print $p->fullName; // Prints "Peter Peterson"
   

   Resources:

   • Original RFC
   • Release notes
   Consider the following:

   If you’re looking for even more background into not just the impact of property hooks, but also the history behind the RFC process in conjunction with Asymmetrics Visibility to replace the older Property Accessors RFC, be sure to check out the great article by Larry Garfield on the topic on the PHP foundation website - How Property Hooks Happened.

2. Asymmetric visibility

   While the visibility of get and set object operations have historically been “symmetric” - that is, both must be public, private, or protected - PHP 8.4 allows for asymmetrics definitions in your objects.

   From php.net:

   Object properties may now have their set visibility controlled separately from the get visibility.

   <?php
   class Example
   {
       // The first visibility modifier controls the get-visibility, and the second modifier
       // controls the set-visibility. The get-visibility must not be narrower than set-visibility.
       public protected(set) string $name;
   
       public function __construct(string $name)
       {
           $this->name = $name;
       }
   }

   Resources:

   • Original RFC
   • Release notes

3. Lazy objects

   PHP 8.4 takes the responsibility of the lazy-initialization of object out of userland, bringing it into the PHP engine itself.

   From php.net:

   It is now possible to create objects whose initialization is deferred until they are accessed. Libraries and frameworks can leverage these lazy objects to defer fetching data or dependencies required for initialization. Object properties may now have their set visibility controlled separately from the get visibility.

   <?php
   class Example
   {
       public function __construct(private int $data)
       {
       }
   
       // ...
   }
   
   $initializer = static function (Example $ghost): void {
       // Fetch data or dependencies
       $data = ...;
       // Initialize
       $ghost->__construct($data);
   };
   
   $reflector = new ReflectionClass(Example::class);
   $object = $reflector->newLazyGhost($initializer);

   Resources:

   • Original RFC
   • Release notes
   • Feature documentation

Deprecations

You can find a list of all deprecations for PHP 8.4 on the php.net wiki.

What’s next?

With 8.4 now released, the road to 8.5 begins with a new round of discussion and voting on RFCs, so be sure to follow the debate there.

Otherwise, you’re all set! Join us in the Discord and let us know how it goes.

Be seeing you!