PHP 8.4 • Hacker News Board

Re: PHP 8.4

#201

Post by mklepaczewski » Thu, Nov 21, 2024, 8:48 PM UTC

nneonneo wrote: post #57

If you want any evidence that terrible language design is alive and well in PHP, look no further than the new array_find function. Not only is it yet another global function in a namespace already chock full of random array helpers, it is extremely similar in both name and usage to array_search - a global function since PHP 4. Except, of course, that in typical PHP fashion, array_find’s argument order is ($array, $fi…

Your IDE should help you with the argument order if that's an issue for you. It has never been a problem for me and I don't understand the argument. I get that it might be confusing the few first times you use these functions, but if you use them every day you just remember the argument order.

The backward compatibility section found only 200-ish projects where array_find() was defined in global name space. For me that's a small price to pay for introducing the new function, and refactoring should BE easy when upgrading a project to PHP 8.4.

Adding array_find() to a namespace would be inconsistent. All other array_*() functions are global.

Re: PHP 8.4

#202

Post by acabal » Thu, Nov 21, 2024, 8:50 PM UTC

hamandcheese wrote: post #180

acabal wrote: post #167

Earlier quoted context omitted.

They are very useful when modeling CRUD-dy objects, because you can lazy-load infrequently-accessed child object using getters. It makes for a cleaner OOP-y interface in which the caller only cares about actually exposed properties and not methods to get and manipulate hidden properties . IMHO using properties directly is a much more natural way to talk about objects, than having a bunch of methods to get properties.…

I do not see any advantage here. All I see (or rather, what can't be seen) is hidden control flow. For what? To save a few characters?

It's a matter of OOP modeling. Object methods are better reserved for performing actions with side effects, or complex logic or calculations, and not for getting state or simply setting public properties; and as a caller, I don't really care about the implementation details of (in my above example) getting the last forums post, I just care that it's a property I can access. (Maybe it came from a cache and not the database? Maybe it was set earlier in the script? I don't care.)

Putting it behind a getter doesn't "hide" control flow. It just makes for a cleaner interface from the caller's perspective.

FWIW, I almost never use setters. Getters are are much more useful, especially for lazy-loading basic properties.

Re: PHP 8.4

#203

Post by lesuorac » Thu, Nov 21, 2024, 8:54 PM UTC

ChrisMarshallNY wrote: post #99

cbg0 wrote: post #90

Glad to see PHP still chugging along after all these years. It's the language I started with as a freelancer more than a decade ago and I still remember having books on my desk learning the proper way to do things, as you had to work around all the unsafe things the language would let you do and which unfortunately led to it getting a bad rep.

One of the issues with creating a language that is easy to use (PHP, BASIC, and many modern languages), is that people who aren't good at programming, will use it. With predictable results. The difference between languages like PHP and more modern languages, is that the more modern languages have more airbags, for the bad code. It's still bad code, but it won't do as much damage. PHP is likely to be around for a long…

I dunno, we just about got rid of the whole "cosmic rays" discussions for computers and finally are getting realistic about the bugs that occur in computers are from bad C code and bad hardware. Neither of those things are easy to use and they have done probably more damage than crappy php code does.

Re: PHP 8.4

#204

Post by acabal » Thu, Nov 21, 2024, 8:56 PM UTC

Xeoncross wrote: post #184

acabal wrote: post #167

Earlier quoted context omitted.

They are very useful when modeling CRUD-dy objects, because you can lazy-load infrequently-accessed child object using getters. It makes for a cleaner OOP-y interface in which the caller only cares about actually exposed properties and not methods to get and manipulate hidden properties . IMHO using properties directly is a much more natural way to talk about objects, than having a bunch of methods to get properties.…

I appreciate the detailed answer, thanks. However, It feels like $a->foo vs $a->foo() is a personal preference that hides the fact you're doing work behind the scenes. Then again, I'm not a fan of code that does magical things that aren't apparent. Makes it a lot harder to 1) reason about and 2) solve performance issues. I also don't want the overhead of function lookups for every property access.

Getters aren't for everything. But for a basic CRUD case like above, they're a nice way of having a clean OOP contract by demarcating a clear difference between properties, which are pieces data attached to the object that the caller can read and write, and methods, which are the caller can change the object's or app's state, or perform actions with possible side-effects.

Very often for a typical CRUD app, I as the caller don't really care how we got the `LastForumsPost`. It's just an object mapping that comes from some data source like the database. And if I do care, I could get it outside of the object, and set it myself.

Re: PHP 8.4

#205

Post by LeftHandPath » Thu, Nov 21, 2024, 9:02 PM UTC

I went to look at array accessor overloading today and saw “Property Hooks” in the sidebar (under “Classes and Objects”).

I didn’t know what they were, so I clicked. I was bewildered that I had never run into them before, used them in my own code, or seen them used by others. Come to find out they’ve only been around for about a day!

Reminds me of some of the lovely expressibility and syntactic sugar that’s pulled me to other languages lately. Glad to see it make its way into PHP.

Re: PHP 8.4

#206

Post by hasnain99 » Thu, Nov 21, 2024, 9:10 PM UTC

I don't Use Php but I think learning Php its better than to learn Typscript

Re: PHP 8.4

#207

Post by int_19h » Thu, Nov 21, 2024, 9:11 PM UTC

ok123456 wrote: post #82

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…

This feature has been in C# since about 2.0, and it's been an overall positive. It reduces boilerplate and inconsistencies in different programmers doing the boiler-plate differently. It also gives static analysis tools semantic information about the structure of your classes. It can group pairs of methods that deal with the encapsulation of fields.

Properties have been in C# since the very first version. And those, in turn, were largely inspired by Delphi, with the honorable mention of Visual Basic.

Re: PHP 8.4

#208

Post by tail_exchange » Thu, Nov 21, 2024, 9:16 PM UTC

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.

Re: PHP 8.4

#209

Post by smt88 » Thu, Nov 21, 2024, 9:18 PM UTC

hparadiz wrote: post #174

smt88 wrote: post #172

Earlier quoted context omitted.

This was weirdly condescending and content-free. I've been programming for 30 years, and getters/setters are both pointless and anti-productive. They hide (potentially a lot of) code from people reading the program, which leads to a lot of "wtf" moments later. Magic in general is bad, and it's the kind of "look how concise and clever I am" thinking that leads to unmaintainable software. If setting a property isn't st…

Every php ORM disagrees. Nothing about it is magic

PHP ORMs and ORMs in general are notoriously hard to maintain. I've written hundreds of thousands of lines of PHP, I'm speaking from experience.

Re: PHP 8.4

#210

Post by wvenable » Thu, Nov 21, 2024, 9:23 PM UTC

hamandcheese wrote: post #195

hparadiz wrote: post #192

Earlier quoted context omitted.

In a typical ORM when you do say $Model->DateTime = 1732046457; the __set is actually checking the value and seeing oh it's an integer. Treat this as a unix timestamp. But when you run save() the query is actually converting that to a Y-m-d H:i:s (for MySQL/MariaDB). This doesn't actually happen until you run save() when it makes the query and runs the network call. Most of that time it's actually storing everything…

That is a fine argument for setters, but I still don't see the connection between that, and the desire to disguise properties as setter methods.

A method is supposed to be an action and a property is supposed to be data. So I don't see the desire to disguise setting data as a "setting method" rather than using the syntax of assignment.