Great PHP release. Better stack traces for closures, performance improvements (always nice), HTML5 support, lazy objects and much more. Great work and a big thanks to everyone involved!
PHP 8.4
71–80 of 337 posts
Re: PHP 8.4
#72Earlier quoted context omitted.
PHP fast? Compared to all popular web frameworks it's quite low in the pecking order when it comes to performance.
Not sure where you got that from. It’s equally if not faster then python, faster then Java, slower then compiled language, faster then ruby. Loses to NodeJS most of the time. But who cares, we are literally talking millisecond differences between them all. Throw a reverse proxy, DB into the mix and a few packages and they are all slow.
> faster then Java
You sure about that? Not what I would have expected. Source?
Re: PHP 8.4
#73Earlier quoted context omitted.
> hopefully hooks will be super short and this won't be a major issue. Even if a PHP project has a policy of short hooks, I think hooks impede clarity. public string $countryCode { set (string $countryCode) { $this->countryCode = strtoupper($countryCode); $this->country = nameCountry($this->countryCode); } get => ... In this short hook, the first line of the setter obviously uses the underlying property. But the seco…
> Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)? To me it is obvious hooks won't use other hooks because that could lead to an infinite loop in a hurry > Does reading `$this->countryCode` use the getter hook, even it's from a `countryCode` hook? same > If not, is there a way to call the `countryCode` getter from this setter? There is although it's a bit tricky and not intuit…
> Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)?
To me it is obvious hooks won't use other hooks because that could lead to an infinite loop in a hurry
I would expect hooks for properties other than `$this->contryCode` to be called inside of a `$this->contryCode` hook.
Btw the docs that are linked in the post[0] seem to be clearer than the example in the announcement. Reads less ambiguously to me.
[0]: https://www.php.net/manual/en/migration84.new-features.php#m...
Re: PHP 8.4
#74Earlier quoted context omitted.
There are of course ways to get "reload page, see results" to work even with Python. After all, computers are touring complete. But in PHP you have it out of the box. Faster, with less complexity and less resource consumption. And you can use the same setup in development as you can use in production.
Maybe I'm missing something, but PHP is not more efficient in that regard. When you load a Python page, it is served by an in-memory process. If code is updated, the process is restarted, parsing the code and initialising the application, but it is done only once. When you load a PHP page, it parses the code and initializes the app for each request . It then tears everything down after the request. There are less was…
This is true when you call PHP using CGI or CLI. Then opcode is build, running and thrown away.
But when u are using FCGI or PHP-FPM then you have running process where opcode is cached except on first request where opcode cache is build.
Re: PHP 8.4
#75These days, I am super torn about what language to use for new web projects. PHP: - Easy to deploy: Upload files, done. - Easy to develop: Reload page, see changes. - Lots of HTTP tooling built in. - Fast. Python: - Great language. - Great code reuse system: Modules. - Nice framework: Django. - Less breaking changes in recent years.
Python’s packaging and dependencies system is lacking, but trying to get better. But too many choices not always compatible nor working perfectly right (should you use pip, poetry or pipenv? Well, you see…) How’s php’s?
> Python’s packaging and dependencies system is lacking
It is? I never had problems with poetry. Though I agree that there are mroe options than necessary.
Re: PHP 8.4
#76Re: PHP 8.4
#77Property hooks are the headline feature, but they seem like something I'd rarely use in practice. It is nice to have the option available though, in case I need to add extra logic to a property without breaking everywhere that it's accessed.
> A primary use case for hooks is actually to not use them, but retain the ability to do so in the future, should it become necessary.
My personal motivation was always to finally put an end to the getters/setters boilerplate.
Re: PHP 8.4
#78I'm just a PHP programmer for work, but I worry about the orientation PHP has chosen. As French people say: better is the enemy of good (Le mieux est l'ennemi du bien). The two new language features bring a higher language complexity for dubious gains. I hope I won't have to work with these. Property hooks mean that some language magic will turn a property access into a call to methods. It implies that `$this->x` has…
I'd tried to put together an RFC years ago to introduce groovy-style accessors in PHP.
$this->foo
would look for a getFoo() method, and execute if it existed, or not if not. Felt like that was easier to reason about, fwiw, but I couldn't get it off the ground. Even then, there were multiple C#-style get/set proposals floating around, so this style seems to be the one more people like. Not a fan of the style, personally, and probably won't use these much directly any time soon. If it helps people maintaining libraries that I use to deliver code that is cleaner and more productive to them... I'm OK with that.
Re: PHP 8.4
#79I'm just a PHP programmer for work, but I worry about the orientation PHP has chosen. As French people say: better is the enemy of good (Le mieux est l'ennemi du bien). The two new language features bring a higher language complexity for dubious gains. I hope I won't have to work with these. Property hooks mean that some language magic will turn a property access into a call to methods. It implies that `$this->x` has…
Don't you get tired of managing getters/setters in your entities?
aren't you just managing them in a new syntax now?
Re: PHP 8.4
#80Earlier quoted context omitted.
> - Easy to deploy: Upload files, done. Sure, it works for simple/less important cases. But it also means that your application code is inconsistent while the files are uploading. Stop your service, upload the files, start the service: safer. For a Django app you would upload files and ask Gunicorn to graceful reload... similar, just cleaner.
Most PHP apps use a deployment method where a symlink gets set to a directory with a new version of the code. Because of how opcache works this has no impact on running requests, while new requests get handled with the new code.
Yes, my point really... it's really not "just upload files" like it's 1997.