Live data from Hacker News

PHP 8.4

php.net

301–310 of 337 posts

Re: PHP 8.4

#301
post #282

Earlier quoted context omitted.

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…

My understanding is that PHP was sort of started by people that did not plan for it like a "serious" programming language, but rather as a tool for specific applications. So it developed features and functionalities as needed with a very pragmatic focus [0][1] [0] the most clear example to me is that since functions are not values and cannot be assigned to variables the way to store a function in a variable is to sim…

[1] is true. Here it is straight from PHP's creator: https://news-web.php.net/php.internals/70691

Re: PHP 8.4

#302
post #200

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

Why should I blame MySQL? It's the PHP developers that decided to introduce it and not change the name, plus have several functions that don't do the right thing as well.

This hasn't been an issue for like fifteen years or whatever.

In hindsight I think it's a good thing, it's a pea that keeps princesses at a distance from the language.

Re: PHP 8.4

#303

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…

The two new language features bring a higher language complexity for dubious gains. For a long time now, PHP has been on a trajectory of trying to be everything to everyone, constantly bolting on features from every language that happens to drift by. My observation has been that the people who are deeply invested in PHP are tired of being hazed online for using a "toy" language, so they're trying to adopt all of the…

PHP was never particularly simple, it has always had a diverse standard library and lots of similar but subtly different builtins and a rather funky type system and so on.

It's not for people that compulsively talk about category theory and lenses five minutes into every programming conversation.

Re: PHP 8.4

#304

Earlier quoted context omitted.

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…

Others will use them and I will need to use their libraries. Get and set magic methods were a mistake too. Same with reflection. Again and again, deeper into the Java 6-land, while Java itself went away a decade ago.

Re: PHP 8.4

#305

Earlier quoted context omitted.

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

Others will use them and I will need to use their libraries. Get and set magic methods were a mistake too. Same with reflection. Again and again, deeper into the Java 6-land, while Java itself went away a decade ago.

> Others will use them and I will need to use their libraries.

From the outside it's just a property access. The whole point is you don't need to worry about whether it's a direct access or a getter/setter with logic, even if it changes from one to the other between versions.

> Get and set magic methods were a mistake too.

They're definitely not ideal, and thanks to this change they're no longer required for the vast majority of cases.

> Same with reflection.

Reflection is a mistake?

Re: PHP 8.4

#306
post #278

Earlier quoted context omitted.

I do it all the time, thank you very much. For a simple web app I don't even need a framework - you can literally create a simple files/folder structure, include files, include folders and get stuff done. An yeah, you can also upload the files by FTP. For something more complicated I'd use WP or Code Igniter depending on the specific project. And then you can again just SFTP those files to the server.

That only works if your application has reasonably few users. Otherwise, your upload will result in some requests hitting a partially completed code base overwrite, that is, only some of your changes have been uploaded at request time, possibly leading to an error. This is a nice strategy for a hobby project, but it plain does not work for a business.

That's not true. For mission-critical apps we route the traffic to the stable version while uploading the new version. This may be similar to what most CI tools do but it doesn't change the fact that we just upload the files and can do it as we see fit. Another good solution is to simply switch off a feature for maintenance while uploading it's files. If your software is well planned, that's a breeze and still keeps the whole process very simple.

Re: PHP 8.4

#307

If you want any evidence that terrible language design is alive and well in PHP, look no further than the new array_find function. Not only is it yet another global function in a namespace already chock full of random array helpers, it is extremely similar in both name and usage to array_search - a global function since PHP 4. Except, of course, that in typical PHP fashion, array_find’s argument order is ($array, $fi…

Your IDE should help you with the argument order if that's an issue for you. It has never been a problem for me and I don't understand the argument. I get that it might be confusing the few first times you use these functions, but if you use them every day you just remember the argument order. The backward compatibility section found only 200-ish projects where array_find() was defined in global name space. For me th…

An IDE can help you write the code, but does not make it easier to read the code.

Re: PHP 8.4

#308
post #307

Earlier quoted context omitted.

Your IDE should help you with the argument order if that's an issue for you. It has never been a problem for me and I don't understand the argument. I get that it might be confusing the few first times you use these functions, but if you use them every day you just remember the argument order. The backward compatibility section found only 200-ish projects where array_find() was defined in global name space. For me th…

An IDE can help you write the code, but does not make it easier to read the code.

Can you elaborate? I'm not sure what you mean, but IDEs definitely make reading code easier. IDE does code formatting, highlighting, argument hints, jumping to methods, declarations, and various hover effects on variables, methods, and classes. Some IDEs offer call graphs and other more advanced tools. Not to mention static analysis that works out of the box in PHPStorm (and I'm sure it can be set up in VSCode).

Re: PHP 8.4

#309
post #167

Earlier quoted context omitted.

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…

They are very useful when modeling CRUD-dy objects, because you can lazy-load infrequently-accessed child object using getters. It makes for a cleaner OOP-y interface in which the caller only cares about actually exposed properties and not methods to get and manipulate hidden properties . IMHO using properties directly is a much more natural way to talk about objects, than having a bunch of methods to get properties.…

Your example seems like an argument against getters. In the case of fetching posts like this I always want to know whether some logic is running. What if the operation is really heavy? When it's a getter you would think it's already loaded.

Re: PHP 8.4

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

Does anyone really FTP files like its 2003? Even in PHP you deploy with some sort of tool, like docker etc. The reload page thing is pretty much solved in all languages with a watcher. entr is a universal one, thats written in C and fast as anything. The thing (most) other languages have is unicode support and concurrency. In PHP there is basically none of these. Fast? You mean fast as in CPU bound tasks? 99.99% of P…

Link those benchmarks please. Both 500 and 10k-30k seem extremely low.
Post reply on HN