←back to thread

PHP 8.5

(stitcher.io)
202 points brentroose | 2 comments | | HN request time: 0.488s | source
Show context
gregoriol ◴[] No.45990274[source]
tl;dr: nothing interesting, just stability and maturity
replies(1): >>45990559 #
Cthulhu_ ◴[] No.45990559[source]
And a pipe operator, which is also being discussed in a number of other languages.
replies(1): >>45991480 #
1. senfiaj ◴[] No.45991480[source]
It seems that pipe operator was introduced largely because PHP arrays and strings don't have "methods". You can't write something in "OOP" style: "some_string"->str_replace("some", "replacement")->strtoupper(). With PHPs array / string procedural way writing such chains is much bulkier. Pipe operator will somewhat reduce the boilerplate, but the native "OOP" style is still much better.

Although there is a proposal for adding "methods" but I don't remember the link.

I'm not a blind PHP hater, but it seems like PHP community members sometimes celebrate new PHP features when their equivalents have been there for many years in other programming languages. https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab...

replies(1): >>45991824 #
2. johannes1234321 ◴[] No.45991824[source]
No, the OOP style isn't better. The set of functions one can use in OOP is closed.

Imagine I want to AfD a custom string function for a feature which uPpErCaSeS every second letter as I need that for some purpose: I can't do in OOP style.

In OOP I could extend the string class, but most other parts of the code won't magically use my string type now.

Thus I have to create a free standing function for this (which probably also is better as I don't need internal state of thee object, thus livingnoutisde is good for encapsulation)

And thus my string function works different from other string functions.

    my_casing($string->trim())->substr(3);
(The example of course is non sensical and could be reordered, but we argue syntax)

Having them all be simple functions makes it equal.

Of course there are alternative approaches. C++ argues for years about "uniform call syntax" which would always allow "object style" function calls, which could also find non-memwbr functions where the first argument is of compatible type, but such a thing requires stricter (or even static) typing, this won't work in PHP.