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

291–300 of 337 posts

Re: PHP 8.4

#291

Post by skissane »

wbl wrote: post #163
inglor_cz wrote: post #45

Earlier quoted context omitted.

"Else you end up with frankenstein code where every file could use a different style." Yeah, this is a huge problem, but also, in the long run, inevitable. Plenty of Kernighan & Ritchie C code still out there...

Almost none: ANSI was over 30 years ago and enough of an improvement people switched. If you mean C89 then yes, loads of it.

It helps there are automated tools for converting old style K&R function declarations to the new ANSI/ISO style, like protoize.

But K&R C is now so dated, protoize was removed from GCC 4.5 and onwards. When (in a bout of idiosyncrasy) I wanted to convert some ancient K&R C to new style a couple of years back, I ended up putting GCC 4.4 in a Docker container to make it easier: https://github.com/skissane/protoize

Re: PHP 8.4

#292

Post by stephenr »

thrw42A8N wrote: post #290
klaussilveira wrote: post #123

Earlier quoted context omitted.

Yes, that is correct. And this release marks a point where the language is officially moving away from that.

How? It just got way more invested into OOP... It's now much harder to understand my code at a glance. The Java feeling isn't because I have to write a lot of code, it's how the code works.

> It's now much harder to understand my code at a glance.

Why? Property hooks aren't mandatory. If you want to keep using explicit getter/setter methods, you can do that. If you want to keep using implicit getter/setter hooks via __get/__set, you can do that. If you want to keep using plain property access, you can do that.

All this does, is allow features that previously relied on the black box of __get/__set to be exposed as real properties. This massively improves the scenario for anything that works via reflection, and makes a whole suite of bugs related to unintended behaviour, simply impossible.

Re: PHP 8.4

#293

Post by stephenr »

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?

A big part of this is about code that's consumed by third parties: i.e. library code.

Previously, it was very common to not expose a public property directly, even if it required no setter logic, because any future change to add setter logic would mean it has to become a setter method.

This results in potentially dozens of boilerplate getter/setter methods, that provide no actual benefit, but are necessary to avoid potential BC breaks in a future version of the library.

With property hooks, the property doesn't need to define any getter/setter logic initially - and adding a hook later to the `set` action doesn't change the way other code calls it.

So no, it isn't just "new syntax" now - it's a case of largely not needing to write/generate any of that boilerplate any more - it's just not needed, regardless of how that property's behaviour changes in future.

Re: PHP 8.4

#294

Post by Liquidor »

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.

Lua has rawget() and rawset() to bypass the magic methods, which is used a lot inside/outside the metatables (objects with magic methods) to avoid magic loops I guess.

Re: PHP 8.4

#296

Post by arkh »

> Object API for BCMath

Really good thing when doing some operations on monetary values. No need to use bc_* functions anymore it seems.

Re: PHP 8.4

#297

Post by arkh »

crimsonnoodle58 wrote: post #213
tail_exchange wrote: post #208

Earlier quoted context omitted.

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.

Or if they could follow Godot syntax: https://docs.godotengine.org/en/stable/tutorials/scripting/g...

var milliseconds: int = 0

var seconds: int:

get:

  return milliseconds / 1000

 set(value):

  milliseconds = value * 1000

Re: PHP 8.4

#298

Post by nilslindemann »

Non PHP expert here, can someone explain to me the line

get => \sprintf("%s_%s", $this->languageCode, $this->countryCode);

in the first code example? Is it a lambda?

Re: PHP 8.4

#299

Post by Timon3 »

shikck200 wrote: post #283
9dev wrote: post #281

Earlier quoted context omitted.

> I now cant tell if im accessing a property or a getter. But you never could have been sure for the last 20-ish years either? What if my library you're using (and you can be certain at least one of them does) includes a class like this: class Foo { public function __get($prop) { return match ($prop) { 'bar' => $this->doSomeHeaveIoOp(), 'baz' => query_db() default => throw new RuntimeError('Invalid property ' . $prop…

Its obvious that this has been possible before. It always was bad practice to do so, no matter of the language. I for see people starting returning `$this` and having these really complex chains of getters. Its going to turn into even more spaghetti, because now there is two syntaxes for basically doing the same thing. It seems simplicity is just something everyone wants to abandon.

> It seems simplicity is just something everyone wants to abandon.

I think this very much depends on your perspective. "Simplicity" isn't a single dimension, you'll always face trade-offs at some point.

While the language did get slightly more complicated with the introduction of property hooks, they also simplify a lot of real-world code. Instead of handling all getter/setter logic inside two big functions, there's now a direct relation between each property and its getter/setter logic. There's a lot of value in that!

Of course you can say that's not good practice and therefore shouldn't be made simpler, but then you're still offloading complexity onto the individual program and developer. They are using these features in production code, and keeping the language simpler means that every class using getters/setters has its own custom logic. That's not simple at all!

To give a real-world example, Typescript supports many things that probably wouldn't be necessary if the language were designed from the ground up. But it's meant to add type safety to Javascript, so it has to support adding types to patterns that aren't best practice. But this also simplifies adding types to the existing ecosystem by a large margin, which is arguably the reason it has become the de-facto best practice for writing frontend apps.

Re: PHP 8.4

#300

Post by gog »

inglor_cz wrote: post #2

I have a question to the PHP-in-production crowd: how long do you wait before migrating to higher version of PHP? Is the first release usually already fine, or is it better to wait for a few months and let someone else catch the early errors?

Usually the release is fine, but dependencies can be lacking in proper support/testing of the newer versions, so it takes a couple of months.

Also external tooling, like for example NewRelic extension, takes some time to release a version that supports the new release.

Post reply on HN