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

211–220 of 337 posts

Re: PHP 8.4

#211

Post by dmsnell »

TheRealPomax wrote: post #173

Standards compliance for HTML is huge. Hopefully everyone switches to it ASAP.

DOM\HTMLDocument is a huge boon. Niels Dosche incorporated lexbor into PHP to do so, and it maintains the same interface as DOMDocument once it’s instantiated.

In case people aren’t aware, DOMDocument is dangerous. You can’t parse HTML with an XML parser; so everyone currently using DOMDocument for HTML would benefit by replacing that with DOM\HTMLDocument immediately, eliminating both security and corruption issues.

Have you tried using an HTML parser?

Re: PHP 8.4

#212

Post by ChrisMarshallNY »

rty32 wrote: post #185
ChrisMarshallNY wrote: post #165

Earlier quoted context omitted.

Wasn't trying to be, but it's my experience that people will deliberately assume the very worst intentions, behind whatever I write, so it's a losing proposition, trying to be circumspect. I am, however, pretty against selling crap. If people pay for my work, or even if they don't (most work I do, these days, is free), they have the right to expect that I did good work. I do run into quite a few folks that write crap…

To be honest, it's a pattern I see under every PHP thread: (Neutral) PHP news -> PHP bad -> PHP not bad Even if people didn't actually say "PHP bad"

I use PHP for my backend work. I am not an outstanding PHProgrammer, because, quite frankly, I don't like the language, but I'm good enough to write fairly robust, secure, and performant backends.

I just hold my nose, write my backend, then get back to my frontend, as soon as possible.

Re: PHP 8.4

#213

Post by crimsonnoodle58 »

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.

Well in python I assume it would be equivalent of accessing:

  self.__dict__['property_name']
And if those PHP rules were in python you could just write:

  @property
  def property_name(self):
      return self.property_name
In actual python though, that would infinitely recurse.

Re: PHP 8.4

#214

Post by hamandcheese »

wvenable wrote: post #210
hamandcheese wrote: post #195

Earlier quoted context omitted.

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.

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

Re: PHP 8.4

#215

Post by joshmanders »

mgkimsal wrote: post #79
conradfr wrote: post #58

Earlier quoted context omitted.

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

aren't you just managing them in a new syntax now?

The difference with property hooks and userland getter/setters is that you're now just doing

    echo $obj->prop
    $obj->prop = 'bar';
not

    echo $obj->getProp();
    $obj->setProp('bar');

Re: PHP 8.4

#216

Post by neonsunset »

signal11 wrote: post #141
ok123456 wrote: post #82

Earlier quoted context omitted.

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.

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 adheres to.

(and personally I'm finding it to be a more productive experience than any dynamically typed language which always feels like stone age regardless of the environment)

Re: PHP 8.4

#217

Post by dctoedt »

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…

> more airbags, for the bad code

Great metaphor. I might steal it for some model contract terms I'm doing (for an expanded version of my contract-drafting course materials). I'd been thinking of "guardrails," but "airbags" is far better.

Re: PHP 8.4

#218

Post by alt227 »

jayflux wrote: post #117
alt227 wrote: post #103

Earlier quoted context omitted.

>but does anyone realistically make websites or web apps that way? You are correct in that a lot of PHP use now is larger frameworks with asset compilation and cache clearing etc, but even when developing on large systems like that it is nice to sometimes be able to just manually tweak a file and refresh. For R&D and quick tests, just uploading a quick & dirty php file to the server is a very useful language feature…

> For R&D and quick tests it is a very useful language feature to have IMO Right, but unless you have an ftp server or quick ssh access and PHP isn’t doing any code caching that feature isn’t an advantage, how many developers are in that situation? Is this something you do? If you’re running locally PHP spawns its own server which other runtimes have. If you’re running this on a server you’re most likely going to hav…

> Right, but unless you have an ftp server or quick ssh access

These days all of that is built right into IDEs

> Is this something you do?

Yes. After linking my IDE to a remote location I can then noodle around with scripts to test whatever. The immediate nature of PHP means the instant you hit ctrl-s your changes are live online.

> If you’re running this on a server you’re most likely going to have app/code caching (apc Or opcache) switched on so you’ll need to restart the server anyway

In prod yes, but in dev environments all that is switched off as its not needed.

Re: PHP 8.4

#219

Post by 9dev »

wvenable wrote: post #168
mgkimsal wrote: post #162

Earlier quoted context omitted.

can't do that if you declare the properties on the class. __get only works for undefined properties.

Well don't do that then. :)

Doctor, doctor, it always hurts when I press here…

Re: PHP 8.4

#220

Post by rty32 »

alganet wrote: post #136
rty32 wrote: post #54

Earlier quoted context omitted.

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…

This would be a valid point 20 years ago. PHP functions can be namespaced. I can just write myLib\array_find, otherLib\array_find. You choose what implementation you want when importing. IDE will pick the correct one. So, zero chances of collision.

Read my comment and all previous comments again.

Don't write such meaningless words and waste your and other people's time when you don't even understand what people are talking about.

Post reply on HN