PHP 8.4: Release Date and Features, August 2024
Originally published on my blog: https://dogan-ucar.de/php-8-4-release-date-and-features-august-2024/
In my previous post for the upcoming PHP 8.4 release, I addressed the expecting changes. Just a few days after the post, PHP announced Property Hooks — a feature that gives me mixed feelings. Today — a few months before the final release — I want to give a second overview to PHP 8.4. The following blog post will address changes to PHP 8.4 that are not addressed in the first blog and Property Hooks. For a full overview, I suggest to read both first.
But before we start, I would like to draw your attention to my new platform for PHP Programming Support. This platform is an explicit, direct and private channel to me and targets PHP developers. On this platform, any individual questions about PHP can be discussed — no matter it is related to a framework, legacy or very specific. The questions will be answered by me within 24 hours.
Interested?
Join The Community
more information on my website.
New Array functions
I can hear you saying: what?! Hasn’t everything already been said about this? Well, it seems like it is not.
There are 4 new features being added to PHP 8.4:
array_find($array, $callback): mixed
: returns the first element in$array
for wich$callback
returnstrue
.array_find_key($array, $callback): mixed
: returns the key of the first element for which$callback
returnstrue
.array_any($array, $callback): bool
: returnstrue
, if$callback
returnstrue
for any element.array_all($array, $callback): bool
: returnstrue
, if$callback
returnstrue
for all elements.
And now, I can hear you saying: shouldn’t this have been part of PHP for years?
Read more about the RFC here.
Would you like me to discuss the new array functions in detail in a blog post? If so, let me know in the comments.
CreateFromTimestamp function for DateTime/DateTimeImmutable
Another feature that sounds so obvious that you wonder why you haven’t missed it before: createFromTimestamp
function for DateTime
and DateTimeImmutable
classes. Prior to 8.4, you have to create a new instance, use the setTimestamp method – two steps instead of just creating an object:
<?php
$dateTimeImmutable = new DateTimeImmutable();
$newDateTimeImmutable = $dateTimeImmutable->setTimestamp(1718337072);
With 8.4, the code shrinks to
<?php
$dateTimeImmutable = DateTimeImmutable::createFromTimestamp(1718337072);
I think this feature is not only needed for readability and DRY — it is also a good thing for junior developers not being aware of theory behind Immutability. For instance, a junior developer not being aware that setTimestamp
will return a new object of DateTimeImmutable
instead of modifying the existing instance will, can easily introduce bugs. These kind of bugs are also hard to see in code reviews.
#[Deprecated] Attribute
In short, this attribute gives developers the ability to mark anything as deprecated. While PHP internal code can do this, PHP developers working on frameworks or libraries have to take a non standardized way to express deprecation. The #[Deprecated]
attribute should unify this.
<?php
#[\Deprecated("use Baz instead", since: "5.9")]
class FooBar {
}
I do not have strong feelings for attributes, to be honest. While I like the syntax and find it useful for some use cases — Override
or Deprecated
are two of it – I think they can very fast get overused. It is totally ok to give some metadata information about your code to get them interpreted by third party tools or the IDE. But once attributes get used for configuration or define application behaviour, a clear red line is crossed for me.
Another point is: Attributes do not really affect your source code unless you apply reflection on it. And using reflection, in turn, should net get overused.
I wrote about attributes, how and why they should get used here in the past. Check it out if interested.
Instantiation and Method Call in one Line
Syntactical sugar, but a good one. Instead of:
<?php
(new MyClass())->myMethod();
we can now call simply:
<?php
new MyClass()->myMethod();
and not only methods — the RFC covers among others, constants, static members and properties too. A very cool feature. I have often complained about the brackets and find that this makes the code easier to read.
New request_parse_body
function
A new function that makes it easier to work with multipart/form-data content type — primarily used for HTTP forms. PHP parses this content type but only for POST
requests by populating $_POST
and $_FILES
. The RFC adds a new function request_parse_body()
to expose the existing functionality so that it may be used for other HTTP verbs. A nice feature that will most likely be relevant for framework or library developers, unless you do not work in legacy environments and must go the bloody way of doing everything yourself.
Conclusion
Although the changes coming with PHP 8.4 are not ground breaking, PHP is still on its journey of evolving. Version 8.4 will mostly likely be released in November this year and a feature freeze is planned for August 13th.