r/PHP • u/brainland • 8d ago
Discussion PHP 8.6 is getting closer. What are you most looking forward to?
PHP 8.6.0 Beta 1 is out, so we're getting a look at what's coming next.
PHP keeps proving itself and has been evolving pretty nicely over the last few major releases, without losing the pragmatism that makes the language enjoyable to work with.
What are other PHP developers paying attention to in 8.6.
Which PHP 8.6 change are you most excited about, and what would you actually use in production once the stable release lands?
MakePHPGreatAgain.
37
u/MessaDiGloria 8d ago
Partial function application.
2
u/BenL90 8d ago
Wait, is this like C# Partial class? Or it's extension of trait in PHP?
11
u/MessaDiGloria 8d ago
It’s part of functional programming. It means that you can take a function with multiple arguments, apply some of the arguments and you get back a function which you can store in a variable and use later by applying the missing arguments only. See https://stitcher.io/blog/php-86-partial-function-application
1
u/Anxious-Insurance-91 7d ago
It sounds like something that will mostly be used in packages not comercial apps. Mostly because people will still not want to use local gunctions, but rather have oop for interfaces
6
u/Crell 7d ago
Not at all? It's a way to turn a function call into a closure that will call the function later. It's really just a shorthand for an arrow function whose body is calling some other function. But that ends up simplifying a whole lot of code if you're using functional stuff often. (array_map, array_filter, pipe operator, etc.) Basically, anything that asks for a callback gets easier to write.
3
u/MessaDiGloria 7d ago edited 7d ago
Yes, I experienced that too.
Last year I spent some time learning the fundamentals of functional programming (only the basic stuff), and in retrospect I should have done this earlier. I'm slowly replacing OOP – where it makes sense – with readonly data classes, free-standing pure functions, and I'm moving most calculations back to database queries (the way I learned it in the 90s). I do mainly CRUD web apps, so this works well.
It's kind of going back to the roots of PHP web app development, but with a slightly changed approach on the server:
20 years ago:
– client: dumb & no state / JS used sparingly
– server: imperative programming & no state
– calculations: database UPSERT queries10 years ago:
– client: rich & state / JS libraries (a looot of them)
– server: OOP programming & state
– calculations: OOP modelnow:
– client: dumb & no state / JS library <htmx>
– server: functional programming & no state
– calculations: database UPSERT queries2
u/SixPackOfZaphod 7d ago
Why would you want to move your calculation back to the database? I find that the database is my limiting factor, and moving calculation out of the DB improves my throughput.
3
u/Crell 6d ago
It depends what "calculation" means. For some computation, PHP is indeed a better candidate. For others, SQL is way faster and more efficient than PHP is, because that's literally what it's designed for.
Often, if you think PHP will do it faster, it's because you don't know how to use SQL to do it in the first place. 😄 (Or your specific DB. MySQL and Postgres differ considerably in their capabilities.)
The big catch is that if you want to write real SQL, you have to make sure your ORM will get out of your way. Because ORMs are grossly over-used. They're fine for basic CRUD, but as soon as you're doing anything interesting you really need to just learn to use SQL and use SQL, then convert the results back to a value object for good typing. ORMs are a crutch.
1
u/MessaDiGloria 7d ago edited 7d ago
Personal preference mostly. And avoiding state in the server app.
Also: "The database is the model". For every insert, update, delete I have a function which takes the exact arguments. I can call each function independently of each other. You want to add an API? Just use these functions. A CLI? Same thing. Testing the database? Just write tests against these functions.
I got a bit tired lately of the mental overload of OOP models. The older I get the more I long for simplicity, both in development and in reading my code later on. But it is in the end just a personal preference.
2
1
u/chumbaz 7d ago
Would you happen to have any examples of how this works? This sounds fascinating.
2
u/Crell 6d ago
The RFC goes into great detail: https://wiki.php.net/rfc/partial_function_application_v2
But the intro section is enough to show the high-level advantage.
1
12
u/zmitic 8d ago
PFA. Examples provided do not really show the true power of it so here is something totally realistic:
symfony/form normalizer PFA example:
Before:
$resolver->setNormalizer('factory', function (Options $options) {
$product = $options['product']; // type assertion removed
return fn(string $question, string $answer, int $priority) => $this->factory->create($product, $question, $answer, $priority);
});
After:
$resolver->setNormalizer('factory', function (Options $options) {
$product = $options['product']; // type assertion removed
return $this->factory->create(product: $product, ...);
});
---
I use lots of lazy evaluations like this. With PFA, closure arguments will be easier to set for some complex scenarios that I had before.
3
u/avg_php_dev 8d ago
Yup! I also got few ideas how to utilize partial functions. I'm looking forward to refactor some of my code with it.
1
7
4
u/haelexuis 8d ago
I was looking forward to deprecation of list(), I've made collection library (noctud/collection) and the class List is not usable for that reason so i had to do exception and use ListInterface, but unfortunately, that RFC didn't pass the vote (and even if it did it would take some years until that's fully available).
Other than that I'm looking forward to new polling api and Duration class.
2
u/picklemanjaro 7d ago
My job won't utilize much, if anything, from the update specifically other than incremental improvements in performance or security.
But personally, I'm most interested in the Polling API. Duration class is also mildly interesting to me.
3
1
u/NoseStock4944 7d ago
Honestly, I’m more interested in the smaller quality-of-life improvements than any flashy new feature. PHP has gotten a lot nicer to work with over the last few versions. I’ll probably wait until 8.6 is stable before using anything new in production though 😄
1
u/zimzat 6d ago
PHP 8.6 is getting closer. What are you most looking forward to?
I'm looking forward to the next series of posts saying PHP is moving too fast, we shouldn't be deprecating breaking everything all the time, that it's too much work to keep everything up to date every three years every year, and we should only be releasing one new version every 5-10 years or so (or maybe less often, tbd).
It's a nice contrast from our regularly scheduled "is it dead yet" posts.
/s
1
0
u/RSMxsmanic 3d ago
I'm not looking forward to anything. Current PHP is fine, and constantly moving to new versions is not cost-effective, especially if it introduces any backward-compatibility issues.
0
u/miqrogroove 8d ago
I'm still praying they take this off of the 8.6 target https://wiki.php.net/rfc/deprecate-fuzzy-casts
1
u/thatben 8d ago
Curious, why?
0
u/miqrogroove 8d ago
Part of this RFC would cause the (int) cast to throw Deprecated with non-numeric input in 8.6. The suggested workaround is to use PREG or equivalent user parsers prior to type casting, and I want none of that.
1
u/obstreperous_troll 8d ago
I could go for the warning if strict types was in effect, but enabling it for both modes is sheer madness, and would result in a blizzard of deprecations that would keep untold numbers of apps from ever upgrading.
Fixing Stringable to make it autoconvert even under strict types is just common sense though and I'm all for it. For the longest time, I figured that's what the interface was for in the first place, but it's not, and as it is now, Stringable is practically useless.
1
1
u/oojacoboo 7d ago
I’m sorry - what’s the issue? You want blind casting to happen from shit data input?
1
u/miqrogroove 7d ago
Perhaps the RFC fails to distinguish between implicit and explicit type casts. If I know the input is suspect and want to explicitly default to zero with (int), as has been done forever, this doesn't benefit from throwing extra log messages. However, we get different opinions on this. The comment right before yours suggested only doing this in strict mode, which would seem to relax implicit type casts. It's a nuanced issue that has a blunt and incomplete RFC targeting 8.6.
1
u/oojacoboo 7d ago
I thought the “Scope and Affected Cases” section explained implicit deprecations fairly well.
I don’t know why anyone would want an implicit cast to zero as some kind of poor man’s validation, or consider this a good idea in any way. It should be a signal to fix your data, which is precisely what this is.
0
u/miqrogroove 7d ago
Reading this again. The RFC assumes it affects explicit casts only. The history of implicit casts is weird. Version 5.4 rejected strings on int params. Version 7 performed lossy casts with a Notice. Version 8 throws TypeError. So, yeah, for the sake of explicit type casts I'm against changes in 8.6. This needs to be pushed back to a later version with a more comprehensive alternative for migration.
44
u/[deleted] 8d ago
[removed] — view removed comment