PHP 8.4 introduces several new features and enhancements aimed at improving usability, performance, and developer productivity.

 

This new php update will contain the following updates:

 

 

1. Asymmetric Visibility

This new feature allows developers to define different access levels for reading and writing properties. For example, a property can be publicly readable but writable only within the class. This enhances control over object properties and is particularly useful for encapsulation.

 

 

 

 

 

2. Array Helper Functions

 

PHP 8.4 introduces several native array utility functions:

• array_find(): Finds the first element that satisfies a given condition.

• array_find_key(): Retrieves the key of the first matching element.

• array_any() and array_all(): Check if any or all elements in an array meet a condition, respectively. These functions make array manipulation more intuitive and eliminate the need for third-party libraries.

 

 

3. Improved String Handling

 

New functions like mb_ucfirst, mb_trim, and grapheme_str_split improve support for multi-byte and internationalized strings. These updates help developers handle complex text processing tasks with less custom code.

 

 

 

 

 

4. HTML5 Support

 

PHP now includes a \Dom\HTMLDocument class for native HTML5 parsing, making it easier to work with modern web structures while maintaining backward compatibility with older parsing methods.

 

 

5. Lazy Object Initialization

 

Native support for lazy objects allows developers to defer object instantiation until they are accessed, improving performance and reducing memory usage in resource-intensive applications.

 

 

6. Exit and Die as Functions

 

The exit() and die() commands are now treated as proper functions. This improves consistency and allows these commands to support features like named arguments and strict typing.

 

 

 

 

 

7. Bcrypt Security Update

 

The default cost for bcrypt hashing has been increased from 10 to 12, making password hashing more secure by requiring more computational effort for cracking attempts.

 

 

 

 

 

8. Implicit Nullable Types Deprecated:

 

PHP now requires explicit nullable type declarations (?TypeName) instead of inferring nullability from default values. This change reduces ambiguity and ensures clearer code.

 

 

 

 

 

9. Object-Oriented API for BCMath:

 

PHP introduces an object-based API for BCMath, allowing arithmetic operations with overloaded operators. This simplifies numeric computations compared to the previous functional approach.

 

 

 

 

 

10. Hooks in Interfaces:

Interfaces now support property hooks, improving flexibility and enabling direct property definitions within interfaces.

 

 

 

 

 

These updates collectively aim to streamline development workflows and modernize PHP’s feature set.

 

 

Php 8.4 will be released on November 21.

 

https://stitcher.io/blog/new-in-php-84

I need an interpreter here. [mention=79]Arantor[/mention], what does all this mean? :P

OK to understand this, I need to drop a bit of background.

 

Modern PHP is what we call 'object orientated'. This means we create objects that represent something in our system, e.g. a user, a forum post, you get the idea. These objects have two kinds of things, methods and properties. A method is a thing you can do with it - for the user object you might define a 'change password' method - the rest of the code doesn't have to care how changing a user's password works or what's involved, it just says 'user object, this is your new password, you deal with the actual mechanics of changing it' (like this might be a change in the database or a call to a third party system, the whole point is the object knows how to do stuff and the rest of the world trusts the object to get it done)

 

Meanwhile we have properties, these are things about an object. For example, for a user, one property would be the email address. All users have one, and the rest of a system can say 'hey, user object, what's your email address' - the object doesn't care why, or what it'll be used for.

 

1. Asymmetric Visibility

When you define properties in objects before 8.4, they're either public, protected or private. If I have a user object that has a public email address, any other piece of code given that user object will be able to just request the email address from it - and update it. (Whether that item will save is a different question. Think of it as when you get the user object you write down all the details on a piece of paper, and you carry that piece of paper with you, and literally anyone who can see the piece of paper can read what's on it but also write on it)

 

In other words: a public property is one that an object has that the rest of the code can both read and edit. Protected and private properties, by contrast, are not visible or editable to anything outside the object itself. For example, your user object might say the password is protected - nothing else can just ask the user object for it and arbitrarily be given it.

 

But there is a space for properties that you might want to be easily readable but not easily changeable - you can do this today but you have to mess around writing helper functions to do it, and this newer method is much tidier.

 

 

2. Array Helper Functions

Arrays are lists of things, and it's very common to need to find things in the lists. What that usually means is having to write a bunch of boilerplate when you need to do that, and to write code to go through every item in the list and make a new list of the ones that match the criteria you're looking for. These are tidy ways to do that fairly common set of things.

 

 

3. Improved String Handling

PHP's always been a bit flaky around certain things with text where you're handling non-English text. For example, there's been a function called ucfirst() for years - uppercase the first character, so 'hello world' would become 'Hello world'. But if that first letter were accented, ucfirst() doesn't work and you have to go off and do a bunch of manual work to figure out if it's accented and then to do the conversion yourself.

 

PHP's library for handling this stuff just got a bunch of extra tools (like a version of ucfirst() that can handle accented letters better)

 

 

5. Lazy Object Initialization

So earlier we talked about objects, with all their properties - but to actually make an object you have to go through some hoops. This is a way of skipping the hoops until you actually need to do them, which for a lot of cases will make things faster (since you might get a collection of objects but only actually need the first one)

 

 

6. Exit and Die as Functions

This is just tidying up the language; most things in PHP are either objects (so, code that represents a thing and remembers something about what state it is in) or is a function (a block of code that you feed some information into and get an answer out of). exit and die, though, were special cases that sort of acted like that (you put a thing in and you get an outcome out, namely the end of the script run) but they also behaved as not-functions for certain other cases.

 

Better to just consistently be functions.

 

 

7. Bcrypt Security Update

Bcrypt is a modern way of hashing a password (it's not encryption because you can't undo it to get the original password back) and one of the things this does is 'put the password in, run the same operation on it over and over and over'. The more times you run the encryption, the harder it is to break, and they've upgraded it from 'do this 10 times over' to 'do this 12 times over' for more secure password storage by default.

 

 

8. Implicit Nullable Types Deprecated

PHP features the concept of 'null', a thing that you don't know what it is yet. The idea being that you logically have 'well I should have this value but I don't know what it is' separate to 'I know what this value is, and it is nothing'. E.g. second line of address for many people is blank - but there's a key difference between 'do I have a second line of address' and 'I know I do not have a second line of address'.

 

This extends to functions, where a function says 'I need these pieces of information' and you say what types of information they are, and you can say 'if you aren't given this piece, here's what you can do instead'.

 

Now, you can also say as part of this 'you might get this information, you might not, we might not know it yet' and legacy code would say '$variable = null' for this to say 'we might not know it yet, and if that's the case, use this magic value null as a placeholder'. But this is only an inference, and if you're going to the trouble of saying something like 'string $variable = null', you're saying it should be a string but null is acceptable... which really is saying 'actually I accept a string or null' not 'I accept a string only', so this is a thing about making it more strict and clearer what a function expects to be given, and what it would refuse as 'you didn't give me what I needed, something went wrong'

 

 

10. Hooks in Interfaces

This is a really sexy one for a lot of complex stuff. We talked earlier about properties, but sometimes when you have properties, they're not simple bits of information about your object. Sometimes you'll have a property and when other people ask for it from you, you want to give them a more useful format. You could always do this, for the record, but it was always hella tedious to roll your own getters and setters to mimic this behaviour.

 

e.g. I have a book object, the book object internally knows which authors wrote it, but I might want to be able to define a 'credits' property where I can just conveniently ask for 'the names of all the authors, as a simple string in the format of "name, name, name"' - now I can do that in a very short piece of code.

 

 

Basically all of these are things are either strictness (making it easier to write good code because PHP will be better able to warn you that something isn't right), or convenience where you could always have done it but this lets you do it quicker and easier and usually faster to run too.

As I am a web developer for me this is really good news, I am already working on a PHP project building a twttier style website so for sure this new update would help me even more.

BI would mentioned below quick simple explanation of the updates in PHP 8.4 for new developers:

1. Asymmetric Visibility: You can control who can read and write a property. For example, everyone can see a value, but only the class can change it. This is useful for keeping your code safe and organized.
   
2. Array Helper Functions: New built-in functions make working with arrays easier:
    
   
   • array_find(): Find the first item that meets a condition.
     
   • array_find_key(): Find the key of the first matching item.
     
   • array_any() and array_all(): Check if any or all items meet a condition.These save time and reduce the need for extra code.
     

[*]Improved String Handling: New functions help handle special characters and text from different languages more easily, like capitalizing the first letter (mb_ucfirst) or splitting text (grapheme_str_split).

[*]HTML5 Support: PHP now has a tool (\Dom\HTMLDocument) to work better with modern HTML5 structures. It’s more efficient for web development.

[*]Lazy Object Initialization: Objects are only created when you use them. This saves memory and improves performance for large apps.

[*]Exit and Die as Functions: The exit() and die() commands now work more like regular functions, making them easier to use in modern PHP coding.

[*]Bcrypt Security Update: Password hashing is stronger by default, making it harder for hackers to crack passwords.

[*]Nullable Types: You must now clearly say when a variable can be null (e.g., ?TypeName). This makes your code clearer and less confusing.

[*]BCMath Improvements: You can now use objects for math operations, making calculations easier and your code cleaner.

[*]Hooks in Interfaces: Interfaces now support properties directly, allowing more flexibility and modern designs.

These updates make PHP faster, safer, and easier to use!

 

If you're not a web developer, it's probably best tostay away from this thread, unless you’ve got a stash of headache pills handy. Trust me, this one's a brain workout 🤣

OK to understand this, I need to drop a bit of background.

 

Modern PHP is what we call 'object orientated'. This means we create objects that represent something in our system, e.g. a user, a forum post, you get the idea. These objects have two kinds of things, methods and properties. A method is a thing you can do with it - for the user object you might define a 'change password' method - the rest of the code doesn't have to care how changing a user's password works or what's involved, it just says 'user object, this is your new password, you deal with the actual mechanics of changing it' (like this might be a change in the database or a call to a third party system, the whole point is the object knows how to do stuff and the rest of the world trusts the object to get it done)

 

Meanwhile we have properties, these are things about an object. For example, for a user, one property would be the email address. All users have one, and the rest of a system can say 'hey, user object, what's your email address' - the object doesn't care why, or what it'll be used for.

 

1. Asymmetric Visibility

When you define properties in objects before 8.4, they're either public, protected or private. If I have a user object that has a public email address, any other piece of code given that user object will be able to just request the email address from it - and update it. (Whether that item will save is a different question. Think of it as when you get the user object you write down all the details on a piece of paper, and you carry that piece of paper with you, and literally anyone who can see the piece of paper can read what's on it but also write on it)

 

In other words: a public property is one that an object has that the rest of the code can both read and edit. Protected and private properties, by contrast, are not visible or editable to anything outside the object itself. For example, your user object might say the password is protected - nothing else can just ask the user object for it and arbitrarily be given it.

 

But there is a space for properties that you might want to be easily readable but not easily changeable - you can do this today but you have to mess around writing helper functions to do it, and this newer method is much tidier.

 

 

2. Array Helper Functions

Arrays are lists of things, and it's very common to need to find things in the lists. What that usually means is having to write a bunch of boilerplate when you need to do that, and to write code to go through every item in the list and make a new list of the ones that match the criteria you're looking for. These are tidy ways to do that fairly common set of things.

 

 

3. Improved String Handling

PHP's always been a bit flaky around certain things with text where you're handling non-English text. For example, there's been a function called ucfirst() for years - uppercase the first character, so 'hello world' would become 'Hello world'. But if that first letter were accented, ucfirst() doesn't work and you have to go off and do a bunch of manual work to figure out if it's accented and then to do the conversion yourself.

 

PHP's library for handling this stuff just got a bunch of extra tools (like a version of ucfirst() that can handle accented letters better)

 

 

5. Lazy Object Initialization

So earlier we talked about objects, with all their properties - but to actually make an object you have to go through some hoops. This is a way of skipping the hoops until you actually need to do them, which for a lot of cases will make things faster (since you might get a collection of objects but only actually need the first one)

 

 

6. Exit and Die as Functions

This is just tidying up the language; most things in PHP are either objects (so, code that represents a thing and remembers something about what state it is in) or is a function (a block of code that you feed some information into and get an answer out of). exit and die, though, were special cases that sort of acted like that (you put a thing in and you get an outcome out, namely the end of the script run) but they also behaved as not-functions for certain other cases.

 

Better to just consistently be functions.

 

 

7. Bcrypt Security Update

Bcrypt is a modern way of hashing a password (it's not encryption because you can't undo it to get the original password back) and one of the things this does is 'put the password in, run the same operation on it over and over and over'. The more times you run the encryption, the harder it is to break, and they've upgraded it from 'do this 10 times over' to 'do this 12 times over' for more secure password storage by default.

 

 

8. Implicit Nullable Types Deprecated

PHP features the concept of 'null', a thing that you don't know what it is yet. The idea being that you logically have 'well I should have this value but I don't know what it is' separate to 'I know what this value is, and it is nothing'. E.g. second line of address for many people is blank - but there's a key difference between 'do I have a second line of address' and 'I know I do not have a second line of address'.

 

This extends to functions, where a function says 'I need these pieces of information' and you say what types of information they are, and you can say 'if you aren't given this piece, here's what you can do instead'.

 

Now, you can also say as part of this 'you might get this information, you might not, we might not know it yet' and legacy code would say '$variable = null' for this to say 'we might not know it yet, and if that's the case, use this magic value null as a placeholder'. But this is only an inference, and if you're going to the trouble of saying something like 'string $variable = null', you're saying it should be a string but null is acceptable... which really is saying 'actually I accept a string or null' not 'I accept a string only', so this is a thing about making it more strict and clearer what a function expects to be given, and what it would refuse as 'you didn't give me what I needed, something went wrong'

 

 

10. Hooks in Interfaces

This is a really sexy one for a lot of complex stuff. We talked earlier about properties, but sometimes when you have properties, they're not simple bits of information about your object. Sometimes you'll have a property and when other people ask for it from you, you want to give them a more useful format. You could always do this, for the record, but it was always hella tedious to roll your own getters and setters to mimic this behaviour.

 

e.g. I have a book object, the book object internally knows which authors wrote it, but I might want to be able to define a 'credits' property where I can just conveniently ask for 'the names of all the authors, as a simple string in the format of "name, name, name"' - now I can do that in a very short piece of code.

 

 

Basically all of these are things are either strictness (making it easier to write good code because PHP will be better able to warn you that something isn't right), or convenience where you could always have done it but this lets you do it quicker and easier and usually faster to run too.

I'm finally sitting down and trying to learn PHP so this is all gold to me. Hopefully as I learn, it will all start to make some sense.

I need an interpreter here. [mention=79]Arantor[/mention], what does all this mean? :P

Lmao, I was about to ask the same thing. I’ll have to read Pete’s reply after work today, as he definitely took his time to explain again, and I’m running out of time. 😋

For me, I spent much of the last year on a project where several of these would have been really handy and I ended up doing the longhand for many of them.

e.g. I have a book object, the book object internally knows which authors wrote it, but I might want to be able to define a 'credits' property where I can just conveniently ask for 'the names of all the authors, as a simple string in the format of "name, name, name"' - now I can do that in a very short piece of code.

Would you still be able to get an array or would you need to convert that to an array?

 

Is it more of asking how you wanted it presented instead of only given the option (that I know of) to get an array?

In the design thinking for this, the book object would be holding an array of author objects internally and this would be a nice way of additionally getting the names, pre formatted into a standard string format, without having to manually remember to get the array and iterate over the array in the place you need it.

 

You’re not changing what’s actually held, just making a convenient access to it.

 

You’d still be able to get the originally array if you needed something else (assuming the array was made as a public or otherwise exposed property, this won’t always be the case)

You’re not changing what’s actually held, just making a convenient access to it.

So it's essentially going to skip the [iCODE]implode()[/iCODE] (or other means) function if you request it as a pretty string instead?

where I can just conveniently ask for 'the names of all the authors, as a simple string

You probably can’t implode them.

 

If I did this in Laravel (or any other equivalently modern OO-first environment), my array internally isn’t a list of names. It’s an array of author objects. (It might even be something resembling Laravel’s Collection helper which definitely is not an array)

 

You cannot just implode a list of objects unless you’ve gone out of your way to seediness specific methods to say to PHP “if someone tries to use this object as a string, do this with it”

 

But this is really more a case combined with the first thing: you probably have a book object with its array of author objects and you might want to let other parts of the code have access to the real array, but they can have a pre-made digest format.

 

Really it’s about making it easier to define ways to get at the data an object already has. You’re thinking about my example solely in the context of that example, when that’s really not the intent of the feature.

 

OK, better example: I have a system that handles money. Everything is done in fixed precision for accuracy. I have an object that represents the product with its price, in home currency. What I also will need from time to time is the price of that product in Stripe terms. For those not familiar with Stripe’s API, a product that is USD 149.99 is not sent to Stripe as $149.99 - rather it’s sent as 14999 US cents.

 

Since I know I’m going to need the price for Stripe on various things, I define a new property in the current longhand way that says “get me the current actual price, then convert it to what Stripe wants” meaning that I have my product and can ask for $product->price_regular and get its price for normal purposes as well as ask for $product->price_stripe and get it ready formatted for Stripe without having to duplicate the logic everywhere I would otherwise need to do the conversion. I also never want to allow anything to override this value.

 

Similarly I can define $product->tax_amount as a property where the rest of the system can just trust that the product knows how much of its own price is taxable and therefore how much tax is liable.

 

What we’re really saying here is that in the pre 8.4 world we can define properties that are either read/write or not accessible (with no easy gated update method) and any additional behaviour is much more longhand, and that in 8.4 we can very easily define any type of attribute we like and make it very easy to define “if you get asked for this, here is what you do and if you get asked to update it, here is what you do” including “you can look but you can’t touch” attributes and entirely derived or computed attributes that are made from something else.

Lmao, I was about to ask the same thing. I’ll have to read Pete’s reply after work today, as he definitely took his time to explain again, and I’m running out of time. 😋

Without being too much of a brown noser here, I've always looked to Pete for programming advice and thoughts. He's good!

I try to be helpful, because I’ve long been a believer that this stuff isn’t magic and that if people want to learn, I’ll try to share what I know - I am just mindful my communication and explanation style don’t always translate well.

You cannot just implode a list of objects unless you’ve gone out of your way to seediness specific methods to say to PHP “if someone tries to use this object as a string, do this with it”

That is the entire point of __toString() :) no going out of your way and its not seediness :)

I have no memory of what I intended to write there, but it was very definitely not that and I got autocucumbered again.

 

As for the example, again that's a limit of my bad example, though if you have a book with a collection of book authors, you don't want to implicitly convert the book to a string (and if you did, you'd probably want to convert the book's title instead), but you can't overload an array with __toString() which means you're either writing a custom accessor (which is really all the new get/set syntax is) or you're creating a collection class solely for the purpose of being a collection whose default type-cast to string is to iterate over all the members, coerce them to string, and implode the rest.

 

For me such a collection would be oddly specific and I'd probably just roll it up into a function on the book object anyway, but that just leads me back to having a tidier version on the class as a computed property.

 

(I have written custom collection classes, e.g. the one project at work has one, but it's there specifically as a form of optimisation where I need to work on the same collection twice over, doing different things the two times but I don't want to fresh-load the collection in between, so it's really a collection with a specific deep clone function that manages resetting state, and applying specific transforms to every member of the collection)

https://www.php.net/manual/en/language.oop5.magic.php#object.set-state

 

Should be explicit to the instance ;) IE also, not seedy :)

[mention=79]Arantor[/mention], man I wish you would join the Axleus Discord. Got sooo many cool things that are upcoming. Component based framework development with a comparable developer experience to laravel.

I say comparable, but I should really say better dev experience than laravel, or at least that is the goal.

That’s one heck of a tall order given that Laravel is more than 10 years in, has a massive first party ecosystem that covers dev environments, managed servers, serverless and soon private cloud, and that the code ecosystem includes pre-built auth flows including 2FA, SSO with OAuth, websockets support, Stripe wrapper, first party dashboard components, and so much more.

 

Not saying it can’t be done but don’t underestimate how good the Laravel DX is given how much of an ecosystem it has, and the head-start they have.

Oh, trust me, I totally understand how far ahead they are and that's ok. But, I truly believe it can be done and working on doing it.

I did originally try to leave this as a profile comment under your link but it was too long (hah) so I will leave it here. Thoughts based on looking at the repos you linked me to.

 

I get that you’re going for Mezzio’s views philosophically but for me that’s not actually a great DX. I don’t particularly care that every module is swappable because I’ll go with whatever everyone else goes with - because it’s convenient and means others will find it familiar (which is a key requirement for me).

 

As I get older I find I care less about the intellectual purity and correctness standpoints in favour of “I need to do this very typical thing like all the other things, what’s the quickest and easiest way to do that” because often my clients want it done affordably, it’s not about the “perfect” but being good enough I don’t need to worry about it.

 

Laravel lets me get going, stays out of my way with a consistent approach for the stuff I don’t generally need to change, and lets me easily change the stuff I might (but rarely do in practice), and means I can hand it over to someone else to maintain without explaining how the framework works.

 

It’s like the discussion that happened ages ago on SMF about making it hot-swappable to use Silex/Slim/Symfony and others, and my point is that while that’s technically cool, it doesn’t actually solve the real world problems, while engaging in a lot of effort for the sake of it - yes, modular is great, yes letting devs pick and choose is cool, but only if it doesn’t get in the way of the users. Such an SMF for example front loads the conversation with “which one do I use” (as opposed to picking a sensible default that everyone can adopt) and forcing certain cross-combinations of “well I want this because I want to use that and that depends on it, but that then rules out this other thing I wanted to use”, which you’d think shouldn’t be a problem with well-architected interface-driven code but the reality is that virtually everything ends up reverse engineering the interfaces to fit the implementation anyway, so all the good SOLID stuff (esp the L) goes out the window, and you have this multi-headed hydra that is conceptually cool but ultimately frustrating to work with.

 

Bottom line: I think the approach you’re taking has an audience, just an audience who has a different set of concerns to what practically and realistically affect me or what I want to build on. And for that audience it delivers in abundance, it’s just a shame that I don’t really belong to that audience any more.

Laravel lets me get going, stays out of my way with a consistent approach for the stuff I don’t generally need to change, and lets me easily change the stuff I might (but rarely do in practice), and means I can hand it over to someone else to maintain without explaining how the framework works.

This is really, where its going just for the Mezzio ecosystem. The target audience are those folks that freelance but need or want the flexibility that is offered, just with an expanded package set to "get started quickly" with packages that are as flexible as the framework itself.

 

Who knows, I might put a couple years into it and it may go nowhere, or it might gain some traction. Time will tell. It'll be a fun journey either way :) I mean after all, I just wanna build cool stuffz :)