---
title: 'What''s new in PHP 8.4 (and 8.5) | Derick Rethans | phpday 2025'
source: 'https://youtube.com/watch?v=TibFBqtv_CI'
video_id: 'TibFBqtv_CI'
date: 2026-06-21
duration_sec: 2418
---

# What's new in PHP 8.4 (and 8.5) | Derick Rethans | phpday 2025

> Source: [What's new in PHP 8.4 (and 8.5) | Derick Rethans | phpday 2025](https://youtube.com/watch?v=TibFBqtv_CI)

## Summary

Derek discusses new features in PHP 8.4 and previews upcoming additions in PHP 8.5, focusing on improvements to typing, property hooks, performance, and developer tooling. The talk covers asymmetric visibility, property hooks, new DOM parsing, a rewritten JIT engine, and several new functions for Unicode handling.

### Key Points

- **Asymmetric Visibility in PHP 8.4** [0:41] — PHP 8.4 allows asymmetric visibility for typed properties, enabling public reads and private/protected sets without explicit getters/setters. The 'set' visibility must be equal or higher strictness than 'get'.
- **Property Hooks** [5:13] — PHP 8.4 introduces property hooks (get/set) for typed properties, allowing logic to be attached directly to property access. Supports virtual properties (no backing storage) and actual properties with storage.
- **New on Construct Syntax** [10:05] — PHP 8.4 allows `new ClassName()->method()` without double parentheses, requiring parentheses after the class name to avoid ambiguity.
- **Pipe Operator (PHP 8.5)** [11:04] — PHP 8.5 may introduce a pipe operator for chaining function calls (e.g., `$value |> fn`), currently in voting, with restrictions on multiple-argument functions requiring closures.
- **HTML 5 Parsing** [14:39] — PHP 8.4 adds a new `DOM\HTMLDocument` class using an HTML 5 parser, separate from the old HTML 4 parser, allowing opt-in upgrade. Also fixes XML conformance in `DOM\XMLDocument`.
- **New JIT Engine** [17:52] — PHP 8.4 replaces the 8.0 JIT with a new one based on a custom intermediate representation, easier to maintain and support ARM CPUs. Performance gains are modest but maintainability improved.
- **Deprecated Attribute** [21:53] — PHP 8.4 adds a `#[Deprecated]` attribute for functions, methods, class constants, etc., triggering a deprecation warning when called. Accepts optional message and 'since' parameters.
- **No Discard Attribute (PHP 8.5)** [24:15] — PHP 8.5 introduces `#[NoDiscard]` attribute to warn when a function's return value is ignored, useful for immutable methods like `DateTimeImmutable::setDate()`.
- **PDO Subclasses** [26:34] — PHP 8.4 introduces driver-specific PDO subclasses (e.g., for MySQL, PostgreSQL) via `PDO::connect()` factory method, enabling driver-specific methods and types.
- **Grapheme Functions** [30:05] — PHP 8.4 adds `grapheme_str_split()` to split strings by grapheme clusters (user-perceived characters), handling emojis and diacritics correctly. PHP 8.5 adds `grapheme_levenshtein()`.
- **Deprecated Implicit Nullability** [33:15] — PHP 8.4 deprecates implicit nullable types (e.g., `function foo(Type $param = null)` now requires explicit `?Type` or `Type|null`).
- **Policy Changes** [34:57] — PHP project unified governance rules into a single document. Release cycle changed to 2 years normal support + 2 years security support, ends on Dec 31 of 4th year, fewer release candidates, and allows minor features in beta.

### Conclusion

PHP 8.4 brings significant improvements to type system expressiveness, property handling, performance, and tooling, while PHP 8.5 previews further refinements. Developers should plan for the implicit nullability deprecation and explore new Unicode functions for better internationalization support.

## Transcript

[Music]
So, hi, I'm Derek. I'm European living
in London. Um, we can talk about why I
call myself European in a moment. Um, I
work for the PHP Foundation partly. I
also work on XDbook and I work on PHP
datetime support. I am also Groot
um without a G. I maintain a PHP.NET
that infrastructure. I like maps, beer,
and whiskey. It's irrelevant to the
talk, but I thought I'd throw it out
there. And if you want to have
questions, you can find me on Macedon or
here on the conference. That's all about
me.
So, I'm going to show quite a lot of
code, quite a lot of old code and some
new code that will not compile quite
just yet in your versions of PHP.
One of the bigger things in PHP 84 is
the continuation of making
typing better, making it easier for you
to add bits of language to to your
applications to not have to do lots of
annoying stuff.
Now, before P384, if you want to do any
kind of uh public reads and private
sets, you had to mark your property as
private and you create a public gutter,
right? That's a very common pattern that
you see a lot. But it means you have to
have cutters and sometimes also setters
to do these things.
Now in PG84 you don't have to do that
anymore. You can now type these things
immediately without having to create a
get or setter which is kind of handy.
There's a few concerns here. Um the
first keyword is for getting. The second
one is for setting but you also need to
use the set in between. There's no get
in between the parenthesis because this
is a very common setting. You have a
public get and a private or protected
set. There's also a shortcut for that so
that you don't have to use a public
keyword. So this implies that it is
public get. You can create any
combination but the strictness of the
set needs to be the same or higher than
the getter. That sort of makes sense if
you think of it. So you can't have a
private get and a public set. It won't
allow that. Again also not very useful.
So this asmmetric visibility um is
actually comes back in a few other
things. There's a few things around
this. So it only works with type
properties. So you can't have a all the
checks that PHP does for properties with
access and things like that read only
and stuff like that. are always only
work on type properties because the
untyped properties they are shortcuted
in some other way. As I said the set
visibility must be equal or less than
the main get visibility. Um if you use
weird array kind of things then that
follows set visibility even though you
might be sort of reading this kind of
weird. Uh the same thing if you inherit
properties they need to have the same
time I mean type and you it is allowed
to widen who can read and write to it.
So you can just like you have a a
private property in an inherited class
you can make it a protected property you
can also do it with a asymmetric
visibility
if you use private set it also makes
your property final. There is some
strange interactions happening with
private properties in classes anyway
because if you have an inherited class
that redefineses your private property
with the same name, they actually
created as two private properties.
They're sort of name space. It's not
something you see unless you like far
dump a an object or something like or
you serialize it because you get some
weird things with null characters in
there. You might have seen that at some
point. But this gets too complicated
with the asmatic visibility. So PHP will
now not allow you to re to have in an
inherited class a property with the same
name as in a class that you're
inheriting. Um read only has been
redefined from um private set sort of to
protected set but still has this right
runs responsibility. So if you use read
only by default it will mean a protected
set which made sort of sense. uh unless
you mark it as private set yourself.
Normally read only properties you can uh
write to in any context that you can
write to as a public property but that
now changes as well with this change.
Now PHP 85 not out yet. This has been um
merged into the codebase but uh it will
survive. I think it's pretty likely but
you never know. is that before 85 you
couldn't have the public and private set
on constants
um it's just left out for some reason
now exact or sorry I should say class
constants here now exactly why you would
want to do that I don't know but
sometimes we add things in new versions
that we've forgotten about
all right
one of the other bigger things in PHP 84
is property hooks so that sort of built
on top of as asynchronous visibility but
in a slightly different way. It
basically allows you instead of having
to define a setter and get a method to
implement that logic directly when you
define a property. So you get the code
together. So basically what the syntax
says here is that if I'm reading the
null the full name property, it will
return the value of this first
concatenated with a space concatenated
with the last name. Don't don't ever
store names like this because names are
way more complicated than first names
and last names. But this is an example
that was in the RFC.
Same thing if you if you write to the
full name property. If you attach a new
value to it, then at first we'll get the
value.
This is a variable that is automatically
introduced into the property hook. I
haven't defined it here anywhere myself.
And you also can't do that. it will
explode it or split it by space and then
write it to the first and last property
and then we set is modified as true
because why not?
So there's an interesting interaction in
here because first and last are actual
properties. They are defined on the
class. We have done that with a in a
constructor here defined as properties.
But a full name property isn't an actual
property. uh if you would debug this uh
an object with this class in XDbug, the
full name property wouldn't show up
because it is there's no storage
attached to it. It's only a virtual
property in a way that you can read and
write to it. But there's nothing stored
with this property.
The moment you use a property name in
either the getter or the setter, it will
have to become an actual property with
actual storage. So that's how PHP does
that. Now I find this a little bit of a
contrived example um but I actually
found some use case in code that I've
written a long time ago where these
propertes are actually quite useful. So
let's go back in time before we had um
no typing in PHP whatsoever. So this is
code that is written in 2003 long or
2004 maybe long long time ago where we
already wanted to have some type
enforcement of type and value um
enforcement on properties that we're
setting. And the way how you could then
do that is by having the underscore set
and also underscore get magic methods
that would get triggered anytime you try
to write to a property that doesn't
exist. And the implementation that we
then did so long ago is we had a
specific property called properties that
would then store these actual properties
as an array element. And because this is
protected or in sometimes private you
couldn't directly read and write to
this. So the way how we would do typing
for um a property setting in this case
UID referencing it's something uh email
related we would check when you write to
this in this get method whether the
value is a boolean and if it's not a
boolean we throw a value exception
PHP of course has its own value
exceptions now um and if it works we
just set it as a value now of course
when we got type properties in PHP tree,
you can rewrite this to something like
this, right? You can just set the type
directly on a property. But there was a
few other cases as well like for the
list limit property, we wanted to make
sure it's an integer, which we can do
with this type definition, but we also
wanted to make sure it is larger than
zero or zero or larger I should say. And
that is something you couldn't do in PHP
yet because you could only enforce the
type. So with PHP 84, you can now
rewrite this. So we check for the
whether it's a number and whether the
value is larger than zero. You can do
that now in your set property.
So set gets called with uh the value and
if the value is smaller than zero then
we can throw these value errors yourself
and then of course when the moment you
throw an exception things will stop. Um
the type itself we don't have to check
with is int anymore. Of course you can
type that directly on the property.
So set and get property hooks are
actually kind of useful. Uh they also um
cause the bug on XD debug because XD
debug checks where you have lines of
code that you can run and it was only
familiar with functions or methods or
files. But this is now an additional
type of function or an additional
location where you can have code. Xbook
didn't know about it. So if you would
set a breakpoint in these things, it
would sometimes refuse to set a
breakpoint because it didn't know there
was actual code on there. That's now
fixed with the release that I made
yesterday. So you should not be able to
have to run into that now.
All right, next one.
How often have you written code like
this where you create a new object and
then you have to have the double
parenthesis because you couldn't call uh
an a method on this directly. PHP84. You
don't have to do that anymore. Yay.
However, you do have to specify the
parenthesis after your class name.
Normally, if you do new class, you don't
have to use a parenthesis. But if you
want to use this syntax, then you do
have to do that. Otherwise, there's an
ambiguity in in the PHP language. Now,
this works not only for direct methods,
it also works for all of the other
things that you can do. Um, again, I
copied this from the RFC just to show
you that it works everywhere. Uh there's
some weird things in PHP sometimes like
this line.
Does anybody write code like that?
Yeah, there's always one. Uh so I Yeah,
please don't do stuff like that.
Unless it's generated code, I suppose.
Right now, this is a PHP 85 kind of
thing. So earlier we could already have
constant expressions. they were
introduced in PHP4 where you could have
an expression in in in this case in a
default value right so I have string
input and then array callbacks that has
a default value that has the closures in
it but this wasn't allowed yet in PHP85
this is some so this is something that's
going to be newly allowed in PHP85 but
there's some restrictions to this like
these functions so if it's a method it
has to be a static method if it's a
function they can also not rely on
anything from outside the scope because
they have to be static pretty much. That
also means that the values
cannot rely on either using things like
use because that would have to copy
something in from the scope where you uh
running it or can you use short closures
because that automatically takes at the
outside scope into what you call it. So
you can only do that with uh things like
S3 lower. I mean this is an example here
where I basically have a string like
hello world and then I do a few steps to
um first lowerase it then replace all
the non letters with a dash
remove the dashes on the outside and
then replace all the double dashes with
a single dash those are the four steps
that I'm doing here right this code
isn't particularly very readable would
you agree
however PHP 85 five, we might get the
pipe operator which would allow you to
do things like this which is a lot lot
shorter. I mean it's not the example
isn't quite 100% the same but is a lot
lot shorter. When I just checked this uh
it's currently in voting it was 264 and
five against something like that. So
there's a good chance that we'll make
that into the language.
Um again there's a few restrictions
here. The way what how this works is
like the value on the left hand side
gets put as the first argument into the
function on the or the code on the right
the expression on the right hand side.
So s to lower how many arguments does
accept except one argument.
things like prerec replace accepts
multiple arguments and because it
accepts multiple arguments you cannot do
that directly because it wouldn't know
where to place the variable or the
input. So in these cases you'd have to
wrap it in a short closure that I'm
doing here just to be able to make sure
that the x that the short closer gets
gets put into the the right location in
the u in the call itself. This also
works for static methods or any other
closure that you have. It isn't uh you
don't have to spell it out like I'm
doing here. I think this is kind of
useful. Uh I think it's a good new
addition and I'm pretty sure it will
make it into the language as you go. I
ordered the slide when I was listening
to Roman's presentation.
Right. But there's a few other things in
here as well like um
I put them the wrong way around. That's
why I got confused. So in this case here
I'm using the static functions and stuff
like that. But here I'm also allowing um
the dot dot dot operator which turns
this into closure directly. That is
something that you couldn't do in PHP 84
either but that is something that is new
for 85 as well
and of course with restrictions that
they must be freestyling functions or
static methods.
PHP84 introduced parsing HTML HTML 5 to
be precise. Have any have you ever used
the DOM extension in PHP to parse HTML?
Pretty sure
it's actually fairly problematic because
how many websites are still using HTML
4? It's mostly HTML 5 now, right? And
PHP's parser didn't have an HTML 5
parser. And if you write conforming HTML
4 or 5, then this is usually not a
problem. But the way how HTML 4 and HTML
5 resolve inconsistencies in what you've
written. How does it handle when you
don't have a closing tag? These are
different. The rules for handling these
are different which can cause some
issues. If you want to parse HTML to
make sure that it's conforming, then you
might get the wrong answer and that
could introduce security issues in some
form I suppose as well. Now, so we
looked at an 84 to see whether we can
replace the parser that is part of the
DOM extension of lip XML the library
underneath to see whether we can make
that HTML 5. But the library that PHP
uses doesn't support that. So no, we
can't do that. Also we are thinking
switching the parser from HTML 4 to HTML
5 without letting you know is also not a
great idea as an understatement. So the
plan came uh out of that that we find a
new library that can parse HTML um and
then create a a wrapper around that that
you have to opt into.
So we created a new namespace the DOM
namespace and we put in there the
abstract class document which is
basically what the original DOM document
class was and then there is a XML
document in the namespace and an HML
document in that namespace that's um the
HTML specific one then will use an HTML
5 parser whereas if you would use the
normal DOM or DOM HML document I
actually don't even remember what it's
called now would still use the old HTML
4 parser.
Which means if by changing a line in
your code by going from DOM document to
DOM/ document or actually DOM/HMTML
document uh that's the only thing you
need to change to upgrade from a HML 4
parser to an HML 5 parser
to be consistent in the same name space
we also created the XML document class
and originally that didn't do anything
except for basically going to the class
that already existed but we found out
that Actually the XML pars in PHP also
wasn't quite conforming to standards. It
was missing uh the way how it handles
properties and there was some function
calls missing and some behavior was
missing. But this also something we
could now fix because by creating this
extra class in this name space. It means
that
we can fix all these things in there and
then you as a user can opt in into using
this fixed behavior. So that also uh
makes it possible to introduce new
functionality without breaking existing
functionality which is something that we
always try to do not always succeed but
always try to do
right PHP 80 head just in time compiler
it make everything
very slightly faster
um
it's it I would call the one and 80 a
experiments And I'm not quite sure how
successful the experiment was. The way
what it does, what a JIT engine or JIT
compiler does. It takes your PHP code
that gets changed into an abstract
syntax tree. We call them a because
that's a lot easier to pronounce. Uh
this a can convert it into an internal
structure. We call it bite code or op
codes. And that the JIT engine if it
sees that specific functions or parts of
code has been used a lot will compile
that directly to something that runs
directly on your CPU. And of course that
runs a lot faster or so you hope. Turns
out PHP is actually a really quick
language to begin with and because this
JIT compiler can only do that for bits
of code that are just PHP code. The
moment you call a PHP function or an
internal function or function of V
itself, it needs to come out of this jet
mode and then when you run PHP code
again, it needs to come back in again.
So that overhead always, well, not
always, but mostly negated
any time where um where the JIT engine
could provide you with some useful
performance boosts. The only real place
where it actually helped a lot is if you
had a bit of code that did algorithms
that didn't really call any other
functions, which is not something that
happens a lot.
So the JIT engine gave a little bit of a
speed boost, but you probably wouldn't
really notice it to be honest. Now
there's also an issue that it was
specifically written for Intel CPUs and
now most of the new Macs are armed
machines and you see that more in cloud
environments as well. And in order to
all the support for that they basically
had to rewrite the whole thing again
which is not great because anytime you
want to support a new CPU type you'd
have to redo all the work. So in PHP84,
Dmitri worked on a new JIT engine based
on a different framework that he also
wrote
uh intermediate representation which is
basically an a for
uh converting the bite code to CPU code
and by implementing a different backend
for this code, it was much easier to
target different
CPUs later on. A lot easier to do.
Now, this replaces the JIT and PHP 80.
You're not going to notice it because it
works exactly the same, although you
might get slightly different bugs. Bugs
happen. It's also a bit faster, but it
also has at least the opportunity to get
rid of or improve on some of the u
issues that the original 8.0 jet engine
had where it is easier to to add
optimizations for for for calling
functions and stuff like that. Now that
work has never happened. So the
performance boost of the new JIT engine
as you call it wasn't much more either
but it was at least a lot easier to
maintain for us. We also changed how you
enable it. Instead of setting the memory
usage from zero to a number you now need
to the default for opcast.jit is disable
instead of enable with no memory was a
bit old. Um it's still part of the
opcache extension. So if you're using
this, you upgrade from PHPA3 to HTV4,
you don't really have to do anything. It
will just work out of the box.
Now, as Roman indicated in the talk,
because the JIT engine, not very many
people know how it works, and it doesn't
really provide a lot of performance. We
actually not sure whether it's worth
keeping um because it does introduce a
whole different code in the engine that
also needs maintaining
um and can have its own box sometimes.
All right, back to some lighter things.
We now get the deprecated attribute
uh which is an attribute you can set on
functions on methods on class constants
or everything. And when you use that,
PHP will warn you when this function
gets called or the code gets loaded that
this function or whatever other element
is deprecated.
The attribute takes two arguments. They
are both sort of free form. The first
one is basically your error message or
your warning message. And the second
one, the since argument is basically a
way of you
describing since when this deprecation
happens. But the value that I've used
here the 2.4 is free form text. So you
can do whatever you want. So in this
case when you then wrote this run the
test three meth fun function you get
this error message. As I said you can
also do this on other things. You can do
this on class constants. You can do it
on methods um and a bunch of other
elements and so on. I think this is kind
of a neat way than having to use a doc
block with deprecated in it that then
your static analysis exon this is now
supported in the engine which is kind of
nice I think to have but it's a small
feature.
Oh yeah, you can also do it on emnum
cases. I forgot about that. I said that.
Now PHP 85 extends this um attribute
system that you can also set attributes
on constants. I'm not talking about
class constants here uh but normal
constants. Again, who still uses global
constants? Not very many. But for some
reason, we had forgotten to add
attribute support for that in PHP when
we introduced them. H5 now allows you to
do this kind of thing.
useful? Yes. Groundbreaking? No.
You can't do it in these cases. It only
works if you use the con keyword. Not if
you have multiple constants in the same
statement or it also doesn't work if you
call define because in this case you set
the attribute on the fine but you're not
declaring the fine. So that makes no
sense. It doesn't do it.
Scandalous. Yes. I'm sure
we also add this new uh element to
attribute so that you can now also
target a constant but
PHP85 introduces however another
attribute. Uh this
has been merged into the codebase which
is the no discard attribute.
Basically, this tells the engine that if
a function that has its attribute set
returns something and then the function
that calls it doesn't look at a return
value and in that case you'll get a
warning. So basically it tells you that
if you call a function with this it must
return something.
So as an example um it was mostly
introduced for userlander but there's a
few situations in PHP where you also
call a function and you need to do
something with a result otherwise
nothing happens right if you have the
original date class if you call set date
on it then it modifies the object so
that's fine but if you use date time
immutable it returns the new object so
if you don't do anything with the result
here you basically throw that
modification away because we internally
now this no discard attribute you now
will get a warning for this. Yeah. And
of course you can do this in your own
codebase as well for the things where it
is important that the result something
either it's important that you do
something with it or it's important that
um if you have code like this to make
sure that um you're not inadvertently
doing something or not do something that
you're supposed to do kind of things. I
think it's a little small feature to add
to the language.
Right.
You can dis you can discard the discard
attribute by using a void cast. Um if
you really want to ignore this.
Why you would want to do this? I don't
know. Uh hopefully at some point our
compiler gets clever enough to just
remove this whole call to set data
because it has no side effects.
Uh so you can't use this card uh when
the function is tied with a void or
never return types because it makes no
sense. Uh for magic methods including
the constructor that require voids
there's also the wake up and sleep and
stuff like that or have no return type
at all. You can also not use it there.
You get an an error and you can also not
use no discard on property hooks because
that makes no sense,
right? Discard.
PHP84 introduces PDO subclasses
and subclasses are basically a way of
making sure that well if you do PDIO or
new PDIO the object that you get back is
a PDO object because you should do new
object or so new class name so you have
to return an object of that name
otherwise it makes no sense
but there are so many different PDO
drivers like the my squ the the
postquest squ the whatever other
Firebird, OBBC ones, escalite, they all
have slightly different behavior. They
have different methods that work on
them. They sometimes have different
constants or or methods that don't
exist right?
And accessing these from a generic
object makes not a lot of sense because
calling get warning code when you're
using post the driver would then have to
check that and then throw an exception
itself where actually this method really
shouldn't exist on the PDO object in
that case but that also you can't do
because an object is an object right so
84 introduces subasses for each of the
different PDIO drivers and on these
drivers or on these subasses we then
have to find the methods that would only
work for the driver. Now, we still can't
return those when you do new PDO because
that has to return a PDO object. But
there's now a new static method or
factory method, however you want to call
those, called PDO connect. You give that
your your DSN, your your connection
string as you did before. And that then
will automatically return a subclass of
PDIO that um implements this um that is
of the correct subtype
um which is kind of nice to have and if
it returns the wrong one then you can do
something with it if you wish to do
that.
Let's say Arizona obviously this should
never happen but you never know.
PDO subasses are kind of useless. So,
now we're going to look at some language
thing. So, we have an emoji, right? It's
the shrug shrugging man emoji, I think.
Uh, what do you think the output of this
is? So, I'm going to split this emoji
into the different characters. What's
going to come out of this? Someone
should shout out. Yeah. Moji baka. Yeah.
Would you want to explain what moji baka
is?
Like this. Yeah, that's it. Yeah, that's
it. Because PHP's internally only knows
about bytes. So, the only way how it can
split up an emoji is in these 12 bytes,
which is not what you want, and you get
weird question marks.
So, of course, everybody knows here that
PHP has better functions for this called
multibite strings, right? What is going
to be the output of this? Anyone want to
shout out?
is not quite moji baki
but it is not what you would expect. You
would expect to get one character out of
it but no you get four out of it.
So you get a generic emoji for person
shrugging. Then there is one for the
color of the skin which renders as
nothing whether it's masculine or
feminine. And then there is a weird
combining combining one that I actually
don't remember what it does. But this is
still not what you want, right? If you
want to iterate over characters, this is
not what you want to get out of it. You
want to get out of it is a single
character. So PHP84 introduces a new
function called you can guess called
graffine string split. So the graphine
subset of functions in the language,
they are part of the intel extension
which does all your fancy uni code
things correctly. So please use these
instead of MB string. Anyone wants to
guess what comes out of this one?
Just a single character emoji. Right. So
this is PHP84. PHP85. Oh yeah, it also
works for other weird characters. So my
my browser actually doesn't render this
hello correctly because this accent and
this accent are actually on the A. So I
guess that's a bug in Firefox or the
library that it uses. So if you run
this, you get the right things out of
it. So it knows that the A is a
character and also the A with all the
accents on top is also considered a
single character and then the French
flag is a single character.
I'm not sure why I picked the French
flag and not the Italian one, but
now there's also a way how to check
differences between different versions
of strings. So in this case, my name is
Derek. It is not Derek with two Rs or
Derek the Dutch way of the name or any
of the 17 variations that I've seen in
my life. So the Levenstein function is a
way of getting out of there a value that
represents the difference
in definition by some algorithm between
the between those two strings. So if you
do that with just the names it will
basically for each deletion of of
character or rep replication of or
insertion it will add one to the
distance. If you want to see a little
bit better how that works you can
actually give weights to the deletion
replacement and insertion and by nicely
using base 10 here you actually can then
figure out what differences are. So in
this case, if I use this with Derek and
Derek, you see that there are no letters
inserted. We can see that there's been
one replacement, which is the C for the
R, and there's been two letters removed,
which is the D and the R.
Kind of useful to have, but what happens
if you have two flags there, two emojis,
right? If you call Leenstein on this,
what what would you expect the answer to
this would be? What would you hope it
would say?
Just ignoring the person sitting in
front there. But no, what would you
expect? I mean, what changes is one
character that changes, right? But
that's not what the answer is. The
answer is two out of this because if you
look at the bytes, there are two bytes
that are different. And these bytes
represent the letters that spell out the
U and the A. So, and the P and the A in
this case or P and the S in this case.
So if you look at this the the
replacements are these two bytes that
switch. We don't want that. You can
guess what comes next. PHP85 introduces
a graphine Levenstein function. I
misspelled it. There's an extra H in
there. Um and of course then the answer
is one because that's what you want to
get out of this.
I like languages.
All right. Some other stuff that you
probably won't like. Um PHP 8.4 before
we deprecated the implicit nullability.
So if you would set a default value as
null then the type for options would be
RST options in this case or null in
PHP84 that will now throw a deprecation
warning. It will tell you sorry that's a
bit too small implicitly marking
parameter options as nullable as
deprecated. So how do you fix this? Yes,
you ask the question mark in front of
the type or you replace it with or null.
Now this uh in my old PHP 53 code this
caused some problem because this is the
style that we had adopted everywhere.
Also it is from what I remember
Symphonies adopted that as their coding
standard for describing nullable types.
So they had to change their coding
standard for that. Sorry, it happens.
Now, however, so far this is a
deprecation. It doesn't mean that the
functionality doesn't work. Deplications
in PHP basically means like in our next
major version, we're going to change
this functionality or remove it. So,
this basically heads up for you that at
some point when PHP 9 gets released,
which is not going to be this year
because we settled on PHP 85 by now.
Could it be next year? Yeah. Uh or not?
I don't know. I can't say but it's
basically a way of you for knowing that
look at this bit of code and you
probably should change it
and it's not hard to change this because
you just need to ask a question mark
right
I've spoken about code now but we also
need to talk a little bit about policies
PHP's
functionality gets introduced by
something we call RFC's requests for
comments or requests for code whatever
you fancy see at a certain time of the
day.
But that is also the way how we uh do
governance of the project, how we do
releases, how we decide what can be in
RFC, what our support time frames are
and stuff like that. But all the rules
for all of these things were are only in
these RFC's.
So if you wanted to look up on how
exactly we do release management or how
releases are made or what can be in a
release or not that was separated in
four or five different documents which
is a pain in the bum if you need to
figure out what is actually the current
rule set. So we worked on a a little
project that would conflate all these
RFC's and put them in one one document
as a first step and then after that we
sort of rewritten all of these documents
to make them useful and readable and now
anytime we want to change any of the
policies the RFC that changes the policy
is a pull request to the policy. So it
all becomes into one document. It's a
lot easier to read than finding
information in many different things.
Now one of the policies that we changed
about release management is oh you can
find them here is the release cycle in
PHP. So PHP for a long long time we'd
have two years of normal support bug fix
support and then one year of uh security
fixes right we always had three alpha
releases three beta releases and six
release candidates. So each of these
takes two weeks.
That makes 24 weeks of time when you
can't actually add new functionality to
PHP, which is more than a third of the
year, which is not great.
I don't think it's great.
We also had some weird languages about
no minor features in beta releases and
stuff like that. or we could introduce
minor features in bug fix releases which
is things that no none of you actually
liking and also we would end support for
version exactly 3 years after it was
initially released. So if PHP 80 was
released on November 17th, 20,
there's a slide, my next slide says so,
then the support would end November
17th 2023.
Um, which is kind of annoying because
it's always a different date. So what we
did immediately in effect, so this
covers everything, every PHP release
that was already out there. We do two
years of support and two years of
security support with some caveats. We
do two fewer release candidates.
Nobody tested the release candidates
anyway. So we can save a month of work
here sort of. So we don't we now allow
new minor features in beta releases, but
no longer in bug fix releases and
release candidates. And the support ends
at the end of the fourth year. So that
means December 31st. In a graph, it
looks like this. So we introduced this
somewhere in 2024. But at that point,
um, PHP 81 was still in normal support
in security support. So we extended that
with a year. PHP 800 had already come
out of support. So that did not get did
not get extended. Uh, also today is not
May 4th, but today is May 15th. I wrote
a slide on May 4th. the slide the
screenshot. So I think this actually
kind of useful. Now at some point in the
future we might have to make changes to
this again uh due to regulation.
Regulation is starting to impact open
source project more and more. And
there's in the EU there's a cyber
resilience act that Roman sort of
mentioned up front as well. Uh P3
Foundation is
helping to write guidelines around that
and hopeing to influence politicians.
It's not easy to do. uh but that might
stipulate that we might have to do five
years of security support in some way or
in some form. We don't exactly know what
those guidelines are going to be but
that is something that can influence um
um yeah politicians can influence open
source now and there will be more of
that as all right slides are going to be
up there or probably are already up
there. If you have questions feel free
to email me. I'm terrible answering
email, but I will eventually answer them
at some point in the next year. I'm not
that bad. But slides there. If you have
questions come
feel free to find me during the
conference. I'm happy to answer more
questions on PHP or XDbug or anything
else. And I hope you found this
interesting. And I would say enjoy the
rest of your two days. Yeah. Thank you.
Thank you.
[Music]