Live data from Hacker News

PHP 8.4

php.net

81–90 of 337 posts

Re: PHP 8.4

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

technically you can do the same thing with python, via python server pages =)

Re: PHP 8.4

#82

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.

Re: PHP 8.4

#83
post #26

Earlier quoted context omitted.

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?

> Python’s packaging and dependencies system is lacking It is? I never had problems with poetry. Though I agree that there are mroe options than necessary.

That's a wild perspective.

Python has the worst packaging ecosystem i've ever seen

Re: PHP 8.4

#84

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…

I agree. PHP is such a simple language to follow but now with these property hooks, if you dont fully understand how they work then the code becomes unreadable due to the magic.

Worse than that, it is possible to read it wrongly which is going to cause many nasty headaches for amateur developers of the future trying to debug PHP code.

Re: PHP 8.4

#85

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.

My experience is that 99% of the work related to geters and seters is handled by the IDE

Re: PHP 8.4

#86
post #65

Earlier quoted context omitted.

> Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)? To me it is obvious hooks won't use other hooks because that could lead to an infinite loop in a hurry > Does reading `$this->countryCode` use the getter hook, even it's from a `countryCode` hook? same > If not, is there a way to call the `countryCode` getter from this setter? There is although it's a bit tricky and not intuit…

> Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)? To me it is obvious hooks won't use other hooks because that could lead to an infinite loop in a hurry I would expect hooks for properties other than `$this->contryCode` to be called inside of a `$this->contryCode` hook. Btw the docs that are linked in the post[0] seem to be clearer than the example in the announcement. Reads…

You are corect that the docs read much clearer. Why would they muddy the concept in the release post?

Re: PHP 8.4

#87

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?

I wait until I need a new feature, or if there's a security issue. I still have PHP 5 apps in production.

Re: PHP 8.4

#88

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…

I just checked the code samples from the article/post.

Property hooks look awesome, they fix something that's my main pain point in PHP nowadays.

All these getters and setters manually coded make it feel like Java. Just completely boring and unusable without some fancy IDE that types all that boilerplate.

It is one great feature of C# that I'm glad PHP is adopting. This code is also easier to extend than the Java-like sea of getters and setters.

(I don't consider any mention of JS code as a valid comparison, if anything we are better ignoring JS existence unless forced to do some frontend)

Re: PHP 8.4

#89

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.

My experience is that 99% of the work related to geters and seters is handled by the IDE

This encapsulation style for OOP is standard; the language should support it and not require additional design patterns or IDE tools.

An argument could be made for adding a sigil so the class user knows this isn't a dumb field, but then if someone wants to upgrade a dumb field to this, as Python encourages, they would need to modify every use.

Re: PHP 8.4

#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.
Post reply on HN