Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8.4

php.net

Post reply on HN
Print view View original

261–270 of 337 posts

Re: PHP 8.4

#261

Post by kijin »

tail_exchange wrote: post #208
eurleif wrote: post #197

I was curious about why setting `$this->countryCode` inside the setter for `countryCode` didn't result in infinite recursion. Turns out this is spelled out in the RFC, but not in the docs: When a hook is called, inside that hook $this->[propertyName] will refer to the “unfiltered” value of the property, called the “backing value.” When accessed from anywhere else, $this->[propertyName] calls will go through the relev…

I'm also not a php developer, but I agree. This seems like a huge footgun. I've never been a fan of this kind of magic, and I wonder how other languages deal with this case.

It might be a footgun, but it will be extremely obvious when it is triggered.

Re: PHP 8.4

#262

Post by chx »

nedt wrote: post #247
vfclists wrote: post #91

For how many years will it get support, security and bug fixes?

If needed you can get LTS from Zend. They still offer security fixes for 7.2 until end of 2026 and 8.3 is supported until end of 2029. But that's just if upgrading every second or third year is too expensive to you.

Zend offerings are confusing. https://www.zend.com/services/php-long-term-support only lists 8.0 and earlier, https://www.zend.com/products/zendphp-enterprise does have a chart showing 8.3 into 2029 but once again the text only mentions 8.0. What gives?

Re: PHP 8.4

#263

Post by kijin »

JodieBenitez wrote: post #56
kijin wrote: post #37

Earlier quoted context omitted.

You can use the same strategy with PHP. Preload all your scripts in opcache. Once you're done making changes, reset your opcache. In practice, any serious project is likely to be version-controlled. Git pull is generally fast enough that it behaves like an atomic change. (By default, opcache will not reload a file that's less than 2 seconds old.)

I'm pretty sure many PHP dev don't know about OPCache. Many of my colleagues don't know for sure. My point is "be aware of the state of your app code and what you execute", and so be aware of the shortcomings of this deployment "strategy". It's sure perfectly fine and easy for small apps / low traffic / not critical apps. I just want to point that it's not inherently good enough and definitely not the universal way t…

Yeah, I've seen cases where even git is not fast enough. That's when opcache preload comes into play. It's still better than manually uploading files over FTP.

Having said that, the "most modern" deployment strategy is to spin up a new container with your new code already loaded, point your LB at the new container, and scrap the old container. No opcache issues. No race condition.

Re: PHP 8.4

#264

Post by nneonneo »

alganet wrote: post #138
nneonneo wrote: post #69

Earlier quoted context omitted.

Seriously? 2k results for array_find in PHP on GitHub: https://github.com/search?q=array_find++language%3APHP&type=... . RFC authors ( https://wiki.php.net/rfc/array_find ) explicitly noted over 600 hits for definitions of array_find, around 30% of which are not false positives - that is, there's a good possibility that there are 200+ implementations of global array_find in just open-source projects. First page hits…

The example you picked: https://github.com/hawind/gdoo/blob/master/app/Support/helpe... Is namespaced. You need to realize that \array_find is different from \Illuminate\Support\Arr\array_find. There is zero chance of collision here. Totally compatible.

IIUC the `use` declaration is including the target namespace (https://laravel.com/api/8.x/Illuminate/Support/Arr.html) in the current scope, not declaring a namespace itself. If you wanted to create a namespace you need the `namespace` declaration, which this file lacks. `helpers.php` is directly included by both `index.php` and `artisan` and the functions are thereby in the global scope of the entire app.

In any case, it wouldn't make sense for that file to be namespaced under Illuminate\Support\Arr, as most of those functions have nothing to do with arrays.

Re: PHP 8.4

#265

Post by alganet »

nneonneo wrote: post #264
alganet wrote: post #138

Earlier quoted context omitted.

The example you picked: https://github.com/hawind/gdoo/blob/master/app/Support/helpe... Is namespaced. You need to realize that \array_find is different from \Illuminate\Support\Arr\array_find. There is zero chance of collision here. Totally compatible.

IIUC the `use` declaration is including the target namespace ( https://laravel.com/api/8.x/Illuminate/Support/Arr.html ) in the current scope, not declaring a namespace itself. If you wanted to create a namespace you need the `namespace` declaration, which this file lacks. `helpers.php` is directly included by both `index.php` and `artisan` and the functions are thereby in the global scope of the entire app. In any c…

Fair enough, you're right!

Anyway, it _could_ have been namespaced. It _should_ have been namespaced. I'm sad for the app author, but he should have seen that coming. His app was developed well after namespaces were introduced.

You're making impossible demands. PHP has chosen to be backwards compatible _to a certain point in the past_, and it is generous in what it decides to keep working.

To expect that 8.4 will care about not breaking some code that was written with 5.2 style is unrealistic.

You're making a time travel judgement. You're saying that PHP should have renamed everything back then to categorized namespaces and broken compatibility _way_ earlier, which is actually a much worse break than the break that actually happened.

Re: PHP 8.4

#266

Post by shikck200 »

Looks like PHP is going even further towards Java. I really loath getters/setters with passion. I really wish PHP instead focused on getting some sort of concurrency builtin and proper unicode string literals. That should be the main focus, instead of copying various features from Java.

Re: PHP 8.4

#267

Post by shikck200 »

mg wrote: post #6

These 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.

Does anyone really FTP files like its 2003? Even in PHP you deploy with some sort of tool, like docker etc. The reload page thing is pretty much solved in all languages with a watcher. entr is a universal one, thats written in C and fast as anything.

The thing (most) other languages have is unicode support and concurrency. In PHP there is basically none of these.

Fast? You mean fast as in CPU bound tasks? 99.99% of PHP code is slow because of IO, and without any concurrency all the other languages beat PHP easily. If you need CPU bound work, you would not pick PHP (or any other scripting language) anyway.

In most benchmarks PHP (with Laravel/Symfony) is barely doing 500req/sec. Compare this to languages in the same space (like nodejs/python) and they run the same program and can serve 10K-30K req/sec.

Having said that python (a slow langauge) is still capable of doing heavy CPU bound tasks with libraries like numpy. Im not aware if PHP can install C dependencies with composer, like you can with pip.

Re: PHP 8.4

#268

Post by nneonneo »

alganet wrote: post #265
nneonneo wrote: post #264

Earlier quoted context omitted.

IIUC the `use` declaration is including the target namespace ( https://laravel.com/api/8.x/Illuminate/Support/Arr.html ) in the current scope, not declaring a namespace itself. If you wanted to create a namespace you need the `namespace` declaration, which this file lacks. `helpers.php` is directly included by both `index.php` and `artisan` and the functions are thereby in the global scope of the entire app. In any c…

Fair enough, you're right! Anyway, it _could_ have been namespaced. It _should_ have been namespaced. I'm sad for the app author, but he should have seen that coming. His app was developed well after namespaces were introduced. You're making impossible demands. PHP has chosen to be backwards compatible _to a certain point in the past_, and it is generous in what it decides to keep working. To expect that 8.4 will car…

8.4 is not even backwards compatible with perfectly working code written to target 8.x. It doesn't materially matter that the code is written in "5.2" style if it was meant to run on only 8.x. Even that style point is arguable. The author uses Composer! And Laravel! And mostly does use namespaces, outside of a few useful helper functions that are reasonably global so they don't keep needing to import them or use namespace prefixes.

Re: PHP 8.4

#269

Post by runevault »

wvenable wrote: post #240
neonsunset wrote: post #236

Earlier quoted context omitted.

https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... edit: the properties reference now documents the 'field' keyword too

That might be all the motivation I need to go move to .NET 9.

.NET 9 has so much good stuff in it. Thing that I randomly realized I wanted only to find out it works in 9 is dictionary access with "related" types (so like if you have a ReadOnlySpan you can use that to find a value from a string in the dictionary via a value type created off the dict).

Re: PHP 8.4

#270

Post by Implicated »

Dylan16807 wrote: post #252
ezekiel68 wrote: post #250

Earlier quoted context omitted.

Funny world where a feature to prevent infinite recursion -- at a moment in the runtime lifecycle where that would make sense -- is somehow viewed as dangerous footgun magic (addresed to: several replies under this comment).

You could prevent the recursion without this magic, by making the access a compiler error.

404 ComPHPiler Not Found
Post reply on HN