Live data from Hacker News

PHP 8.4

php.net

151–160 of 337 posts

Re: PHP 8.4

#151

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…

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

stockholm syndrome is real

Re: PHP 8.4

#152
post #26
post #6

These days, I am super torn about what language to use for new web projects. PHP: - Easy to deploy: Upload files, done. - Easy to develop: Reload page, see changes. - Lots of HTTP tooling built in. - Fast. Python: - Great language. - Great code reuse system: Modules. - Nice framework: Django. - Less breaking changes in recent years.

Python’s packaging and dependencies system is lacking, but trying to get better. But too many choices not always compatible nor working perfectly right (should you use pip, poetry or pipenv? Well, you see…) How’s php’s?

They just added extension support to packagist, so composer looks like a pretty healthy ecosystem that's officially supported.

https://thephp.foundation/blog/2024/11/19/pie-pre-release/

Re: PHP 8.4

#153

Earlier quoted context omitted.

This varies by domain of course, but on the web (PHP's domain), the language in greatest use nowadays by professional programmers is....Javascript.

Because its hard requirement. Its not the case at all on backend.

No, I’m talking about voluntary use of frameworks like react to create websites.

The front end can have very little js and still be fully functional (like this website for example).

Re: PHP 8.4

#154
post #135

I'm most excited for property hooks. Having getters and setters as part of the language syntax was something I dearly missed from my C# days, nearly two decades ago. In my projects I sometimes emulate getters and setters using `__get()` and `__set()` but that's heavy-handed and requires lots of PHPDoc annotation for type checking. Property hooks look awesome!

I'm curious, why do you like getters and setters?

I know the textbook answer is so that every single possible property can become some mutable chain of events so you can swap names or side-effects without the caller knowing, but I've yet to find a use for that in real life.

It just leads to builder patterns and other oddities like forced decorators like Java has everywhere. I felt like beans were the realization that perhaps we shouldn't be doing this.

Re: PHP 8.4

#155
post #29

Earlier quoted context omitted.

> Property hooks mean that some language magic will turn a property access into a call to methods. __get / __set was doing that already and some frameworks very heavily rely on those. > It implies that `$this->x` has a different meaning if it's inside a hook or outside hooks. this is a valid critique but hopefully hooks will be super short and this won't be a major issue. Indeed, if your get is not an arrow function…

> hopefully hooks will be super short and this won't be a major issue. Even if a PHP project has a policy of short hooks, I think hooks impede clarity. public string $countryCode { set (string $countryCode) { $this->countryCode = strtoupper($countryCode); $this->country = nameCountry($this->countryCode); } get => ... In this short hook, the first line of the setter obviously uses the underlying property. But the seco…

Why would you write such code though? If you want to store an underlying properly, use a differently named (and private) one:

public string $countryCode { set (string $countryCode) { $this->_countryCode = strtoupper($countryCode); $this->country = nameCountry($this->_countryCode); }

Re: PHP 8.4

#156
post #135

I'm most excited for property hooks. Having getters and setters as part of the language syntax was something I dearly missed from my C# days, nearly two decades ago. In my projects I sometimes emulate getters and setters using `__get()` and `__set()` but that's heavy-handed and requires lots of PHPDoc annotation for type checking. Property hooks look awesome!

this was the one feature i read in here thinking “why would anyone want this?”

seemed like a way to backport poor librar/framework choices to have IDE support but not for new code

Re: PHP 8.4

#157
post #135

I'm most excited for property hooks. Having getters and setters as part of the language syntax was something I dearly missed from my C# days, nearly two decades ago. In my projects I sometimes emulate getters and setters using `__get()` and `__set()` but that's heavy-handed and requires lots of PHPDoc annotation for type checking. Property hooks look awesome!

I'm curious, why do you like getters and setters? I know the textbook answer is so that every single possible property can become some mutable chain of events so you can swap names or side-effects without the caller knowing, but I've yet to find a use for that in real life. It just leads to builder patterns and other oddities like forced decorators like Java has everywhere. I felt like beans were the realization that…

I've always been a fan because if a property turns from a simple value to a more complex interaction that might involve DB operations or other side effects then if a getter is in place you can modify the logic without needing to update widespread code.

Re: PHP 8.4

#158
post #135

I'm most excited for property hooks. Having getters and setters as part of the language syntax was something I dearly missed from my C# days, nearly two decades ago. In my projects I sometimes emulate getters and setters using `__get()` and `__set()` but that's heavy-handed and requires lots of PHPDoc annotation for type checking. Property hooks look awesome!

I've written some auto-getter and setter spawners and with reflection it's pretty do-able to implement proper type checking as long as the type you want to check for matches the type declared on the property. PHP meta-coding is actually quite advanced and pretty accessible compared to what I've done in other languages.

Re: PHP 8.4

#159

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.

Every step on the path to bloat is justified.

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.

Re: PHP 8.4

#160
post #94

Earlier quoted context omitted.

I had similar thoughts, but do appreciate the additional mb_ functions bringing multi byte support to some remaining functions. Also people should be coding defensively with things like “if not defined” when implementing their own global helper functions (or avoid doing that at all)

"if not defined" doesn't help, if your own `array_find` doesn't have the same signature and semantics than the new global then you're screwed. You'd want the opposite: overwrite it if it already exists in the global scope (dunno if that's easy / how that'd work in PHP)

the answer is using a namespace
Post reply on HN