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

61–70 of 337 posts

Re: PHP 8.4

#61

Post by askonomm »

sam_goody wrote: post #47
anttihaapala wrote: post #16

Oftentimes many of the significant new PHP features are to fix the shortsighted implementation in the previous ones - for example this method chaining with `new` - there was precedent already, C++ got it right well before PHP even existed and with the very same arrow operator that PHP borrowed (and so did Java and JavaScript with .), so the question is why did PHP have to get it wrong at first and for so long. Anothe…

I don't get your issue with builtin utilities. The design philosophy of PHP is to include whatever common methods would otherwise be in a popular library. (PHP actually began more as a library than as a language.) This differs from, eg, Python, but doesn't hurt. The decision not not to make methods on the objects, but to include everything in the main namespace (so array_walk instead of Array.walk or Array()->walk et…

There is a RFC on it (https://wiki.php.net/rfc/function-composition) which I'd love if it made it through. Until then Crell's FP library is a good option (https://github.com/Crell/fp).

Re: PHP 8.4

#62

Post by idoubtit »

chx wrote: post #29
idoubtit wrote: post #22

I'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…

> Property hooks mean that some language magic will turn a property access into a call to methods. __get / __set was doing that already and some frameworks very heavily rely on those. > It implies that `$this->x` has a different meaning if it's inside a hook or outside hooks. this is a valid critique but hopefully hooks will be super short and this won't be a major issue. Indeed, if your get is not an arrow function…

> 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 second line of the setter...

Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)?

Does reading `$this->countryCode` use the getter hook, even it's from a `countryCode` hook?

If not, is there a way to call the `countryCode` getter from this setter?

If quickly parsed the doc and the RFC, so I don't have answers (I suppose it's yes, no, no). But even if I knew how this code behaved, I would still think it's much more complex than plain methods.

Re: PHP 8.4

#63

Post by graemep »

notpushkin wrote: post #38
mg wrote: post #25

Earlier 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…

> 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 wasteful ways (most recent are app servers, just like in Python or other langs), but I'm not sure if those are widely used in local development.

There are things like opcode caches that make PHP more efficient transparently, while still feeling to the developer like a reload each time.

There are reliability and development advantages to starting each request from scratch. NO leaks, no state you need worry about.

PHP is very much like serverless.

Re: PHP 8.4

#64

Post by nneonneo »

rty32 wrote: post #54
lofaszvanitt wrote: post #30

Earlier quoted context omitted.

Whats the problem with global namespace littered with utility functions. Do they get in the way? They hurt you? They whisper in your ear? Or with the badly named functions? Or the type juggling? Do they eat your soul?

It could be much easier for user defined functions to collide with standard functions, especially when it happens unintentionally. Someone else creates a function named array_something in the namespace. Maybe it already exists in earlier versions, maybe it happens to collide with one of the four introduced in 8.4. This function is accessible to you in the current scope. Now, you try to call the function like the way…

Rust namespaces everything in the standard library to std:: or core::, and has a clear distinction between them.

However, it does implicitly include the entirety of the std::prelude namespace (https://doc.rust-lang.org/std/prelude/index.html) into every source file, as well as including every macro directly exported under std:: (including println!). This enables the unprefixed use of things like Result, Option, Some, Send, etc.

The prelude and std:: macros are the closest thing that Rust has to a global namespace, and even they can be disabled in crates that specifically request it.

Re: PHP 8.4

#65

Post by chx »

idoubtit wrote: post #62
chx wrote: post #29

Earlier quoted context omitted.

> Property hooks mean that some language magic will turn a property access into a call to methods. __get / __set was doing that already and some frameworks very heavily rely on those. > It implies that `$this->x` has a different meaning if it's inside a hook or outside hooks. this is a valid critique but hopefully hooks will be super short and this won't be a major issue. Indeed, if your get is not an arrow function…

> 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 intuitive but I feel this falls under the "it is enough this is possible, there's no need for it to be easy": "Be aware, the detection logic works on $this->[propertyName] directly at compile time, not on dynamic forms of it like $prop = 'beep'; $this->$prop. That will not trigger a backing value." Using dynamic properties in what should be simple code should be rare enough this is not a problem. It's like a bridge convention, the benefits vastly outweigh the drawbacks.

Re: PHP 8.4

#66

Post by theodorejb »

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

Re: PHP 8.4

#67

Post by chx »

nneonneo wrote: post #59
chx wrote: post #53

Earlier quoted context omitted.

That would be some really old library. Already in 2012 when Composer was released there was PSR-0 and today almost all libraries are Composer managed and using a namespace following PSR-4 which itself is ten years old. A library that old would almost surely not run on PHP 8 unchanged anyways. Surrendering the global namespace to the language is not so bad an idea.

Suppose I want to add some new code to an old website? Or I want to gradually upgrade an ancient code base - twelve years is not so old for PHP, when ancient frameworks like Wordpress are still alive and kicking.

If we hitched language development on Wordpress we would still be on PHP4 as they refused to join gophp5 some seventeen years ago.

Again, an ancient enough codebase which contains a library using array_find will need enough upgrades to run on PHP8 much less PHP8.4 the change from array_find to something else is the least of your worries.

Re: PHP 8.4

#68

Post by [deleted] »

anttihaapala wrote: post #16

Oftentimes many of the significant new PHP features are to fix the shortsighted implementation in the previous ones - for example this method chaining with `new` - there was precedent already, C++ got it right well before PHP even existed and with the very same arrow operator that PHP borrowed (and so did Java and JavaScript with .), so the question is why did PHP have to get it wrong at first and for so long. Anothe…

[deleted]

Re: PHP 8.4

#69

Post by nneonneo »

chx wrote: post #67
nneonneo wrote: post #59

Earlier quoted context omitted.

Suppose I want to add some new code to an old website? Or I want to gradually upgrade an ancient code base - twelve years is not so old for PHP, when ancient frameworks like Wordpress are still alive and kicking.

If we hitched language development on Wordpress we would still be on PHP4 as they refused to join gophp5 some seventeen years ago. Again, an ancient enough codebase which contains a library using array_find will need enough upgrades to run on PHP8 much less PHP8.4 the change from array_find to something else is the least of your worries.

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 https://github.com/hawind/gdoo/blob/master/app/Support/helpe..., a PHP app last updated just two years ago (140 stars, 63 forks) which only supports PHP 8.x. Implementation is thoroughly incompatible with 8.4's array_find.

There are so many more examples. Lots of the hits are from codebases that have seen updates in the last few years. Many more are plugins or other addons for PHP frameworks or apps which are still widely used (WordPress, phpBB, etc.).

Re: PHP 8.4

#70

Post by lenlorijn »

JodieBenitez wrote: post #23
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.

> - 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.
Post reply on HN