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

251–260 of 337 posts

Re: PHP 8.4

#251

Post by lmm »

neonsunset wrote: post #216
signal11 wrote: post #141

Earlier quoted context omitted.

It’s interesting to consider the “magic” criticism in the context of languages like Zig, where devs actively want no hidden control flow. And Properties beyond simple { get; set; } are definitely hidden control flow. But as you said — it’s been there in C# for a while and imho it’s a good abstraction over getters and setters. Even 2005-era IDEs could manage it fine, making it easy to access the property’s get/set cod…

How do you expect properties to interact with IDEs? The argument that C# choosing to offer features that lead to terser implementation seems orthogonal to where you write it. Behavior in property getters and setters may as well be completely hidden from the caller. But the standard expectation is that accessing and/or setting a property should be cheap and not involve much logic, which most of the code out there adhe…

> How do you expect properties to interact with IDEs?

An IDE can highlight non-basic properties in a different colour from basic properties, or underline them or something. That would be difficult for an editor to do as part of normal syntax highlighting.

Re: PHP 8.4

#252

Post by Dylan16807 »

ezekiel68 wrote: post #250
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…

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.

Re: PHP 8.4

#253

Post by stephenr »

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…

The original RFC that led to this feature originally used a special variable to indicate the backing store; that was overwhelmingly disliked, as it was "magic".

Conversely php already has other places where context affects property accesses, and IME it's not the problem you make it out to be.

Re: PHP 8.4

#254

Post by hipadev23 »

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…

> too much magic

The backing value is effectively private to everything but its own get/set methods, that seems fairly straightforward to me.

Re: PHP 8.4

#255

Post by Dylan16807 »

munk-a wrote: post #181
duskwuff wrote: post #177

Earlier quoted context omitted.

> mysql_real_escape2 Blame MySQL for that name, not PHP. https://dev.mysql.com/doc/c-api/8.4/en/mysql-real-escape-str... (And, if you're doing modern PHP, it's just PDO->quote().)

I'm not certain about OP's objection but for me it's less the function name and more the terrible history of how PHP tried to automatically fix SQL injection and instead made everything a thousand times worse. If you're not using bound parameters for user data you're taking a huge risk and making your life multitudes more difficult. PHP's PDO is by far the better option at this point but it suffers from poor enough u…

> the terrible history of how PHP tried to automatically fix SQL injection and instead made everything a thousand times worse

Are you thinking of stuff like magic quotes? mysql_real_escape is not part of an automatic anything. You manually use it to quote each value.

Re: PHP 8.4

#256

Post by lmm »

hamandcheese wrote: post #214
wvenable wrote: post #210

Earlier quoted context omitted.

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.

> A method is supposed to be an action and a property is supposed to be data. I agree! That's why it's wild to allow a setter to do literally anything. You aren't just setting a property, there is a conversion happening under the hood. And the reason I hate it is that code that appears to be infallible, isn't. It can have arbitrary side effects, raise exceptions, have unbounded runtime, etc.

There are many ways to make code misleading. You can write a method called plus and have it do multiplication. You can write a method that sounds safe but looks dangerous. Every language relies on programmers exercising judgement when writing the program.

In a lot of contexts you have something that requires a bit of code but really does behave like a property access, where it's more misleading to make it look like a method call than to make it look like a data access. E.g. using an ORM hooked up to SQLite embedded in the program. Or accessing properties of objects that you're using an EAV system or array-of-structs layout to store efficiently in memory. Or a wrapped datastructure from a C library that you're binding.

Of course if you make something look like a property that doesn't behave like a property then that's confusing. Programmers have to exercise judgement and only make things look like properties when they behave like properties. But that's not really any different from needing to name methods/objects/operators in ways that reflect what they do.

Re: PHP 8.4

#257

Post by immibis »

whalesalad wrote: post #151
conradfr wrote: post #58

Earlier quoted context omitted.

Don't you get tired of managing getters/setters in your entities?

stockholm syndrome is real

This comment is referring to the practice of always writing getters and setters even when they are not needed, then feeling frustrated by the amount of boilerplate.

Re: PHP 8.4

#258

Post by theendisney »

James_K wrote: post #246
munk-a wrote: post #159

Earlier quoted context omitted.

And yet in this wonderful laboratory of a multitude of languages the growth of a language doesn't destroy as much as it offers a larger variety of choice - with good features being stolen by other languages and less good features remaining niche and unique.

Look at C++ or Perl, languages with many features that are quite frequently hated. When you add features, you force users to learn those features. It is not just a "variety of choice" because you know that other people will also take some of those choices and you'll probably have to edit their code at some point. Features are not just added to the language, but imposed on its users. The need to add features to a lang…

The imposed part was funny. I hope I wont have to use anything new. I only had a mild panic attack reading they changed exit() but it was a false alarm.

Why is it that after the human life span expires all of the code should be thrown away?

I remember when my host updated and php could no longer be opened with <? and my websites spilled their guts all over the screen.

Re: PHP 8.4

#259

Post by immibis »

NackerHughes wrote: post #224
littlestymaar wrote: post #130

I find it pretty fascinating that what used to be a beginner-friendly language, with limited capabilities but that is very easy to get started with, has now evolve to a bloated monster full of advanced features that you can't expect to know entirely, with a complex framework and tooling ecosystem to support it. PHP lovers generally don't like acknowledge that, but the PHP we've learned back-end development two decade…

PHP is still definitely a beginner-friendly language that is still very easy to get started with. Setup is as trivial as it always has been, copy a .php file onto a server and you’re good to go. No complicated frameworks or “deployment process” needed if you don’t want them (and most people don’t need them). The difference between it and Java is you’re not forced into the ClassObjectGetterSetterPropertyHookFactoryBea…

Java doesn't force you into that paradigm either. Well, most of it. Your code is still contained within a method within a class.

If you write JSP, you don't even need that.

Re: PHP 8.4

#260

Post by immibis »

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…

What is the practical difference between a prefix and a namespace?
Post reply on HN