Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8

php.net

Post reply on HN
Print view View original

121–130 of 273 posts

Re: PHP 8

#121

Post by zackmorris »

Kim_Bruning wrote: post #42

Finally, after all these years, Named Arguments! https://stitcher.io/blog/php-8-named-arguments

Thanks for that! The only error I see in their implementation is that we can't use variables for the name like:

  $name = 'foo';
  myFunction($name: 'bar');
Thankfully, we can still pass an array with the spread operator like:

  $name = 'foo';
  $array = [$name => 'bar'];
  myFunction(...$array);
I wonder if this would work:

  $name = 'foo';
  myFunction(...[$name => 'bar']);
Thankfully it's rather unlikely that someone would use a variable for the name anyway.

Where this will bite people is when they do meta programming with functions that process functions and function signatures.

Maybe I'm missing something, but I find this to be another tragically missed opportunity. It's just unnecessary friction where there didn't need to be any, which makes me sad. At least they can add variable name support someday, because it's easier to allow something restricted than restrict something that used to work. Hopefully there is a "good reason" for this oversight.

Re: PHP 8

#122

Post by sigzero »

ericbarrett wrote: post #118

Facebook’s backups were written in PHP. Well, the second version was, anyway. (The first version didn’t work so well.) By backups, I mean the central MySQL databases with profile and post information; not media or messages. The “Crown Jewels,” so to speak. It was written by an engineer in a week or so and then handed off to me. I was a storage guy with some programming chops. Fewer chops than I thought. Multiprocess,…

Why did you switch to Python? Surely it wasn't as perfomant and you already had a working solution.

Re: PHP 8

#123

Post by teddyh »

laszlokorte wrote: post #90
combatentropy wrote: post #70

I got spoiled by PHP as my first language. It was so easy to get going. I was surprised to learn that other languages didn't work the same way, when integrating into a web server. Also it has always been rock solid. A bug in my code brought down only that request for that user, totally did not affect or even slow down responses to other users. People have attacked its syntax forever. I avoided the worst of it by lear…

REMOTE_USER as in HTTP Basic auth? the ugly login prompt you can not logout of again?

This Firefox extension adds a logout button:

https://addons.mozilla.org/en-US/firefox/addon/http-auth-enh...

Re: PHP 8

#124

Post by pbowyer »

idoubtit wrote: post #114

I get paid for writing PHP code, and the quality of the official PHP documentation worries me. I've searched for several of the changes introduced by the 8.0 version, and I could not find them. For instance, the page titled "Function arguments" does not mention the existence of named arguments. The last time I wanted to submit a ticket about a documentation bug, I saw that the ticket was already created months ago. I…

The PHP project is severely underresourced. One or 2 core devs are sponsored by their employer to work on the project; everyone else is volunteering, and the pool of people isn't as large as it once was.

And that's for developing PHP itself. Documentation needs people too (there are many arguments for and against adding features without documentation) and the team would welcome new members.

Re: PHP 8

#125

Post by chrisandchris »

lgessler wrote: post #24
sleavey wrote: post #6

> 0 == 'foobar' // true That's PHP7 behaviour that's updated in 8 to return false. I'm not a PHP basher, I really like it these days, but why the heck was that example ever evaluating to true?

I'm kind of surprised they'd change a core language semantic, even in a major update... won't this make upgrading to PHP8 for a large codebase hard to do with confidence?

Strict types (scalar type hints for method signatures) have been around since PHP 7, and since then I would say it is recommended to always use === (with type check) over == (no type check) so one would have enough time to upgrade it‘s code.

And it also just makes sense from the language design perspective to fix that behaviour. Having a major version coming is a good time to fix such stuff imho.

Re: PHP 8

#126

Post by Zancarius »

stevekemp wrote: post #11
sleavey wrote: post #6

> 0 == 'foobar' // true That's PHP7 behaviour that's updated in 8 to return false. I'm not a PHP basher, I really like it these days, but why the heck was that example ever evaluating to true?

'foobar' is coerced into a number, which fails for the obvious reason. So it becomes 0, which means the expression is "0 == 0". Terrible, terrible, behaviour but there are lots of similar examples in PHP because it evolved over time rather than being designed as-is. Some of these things are being fixed over time, like this very example, others can't/won't be.

> Terrible, terrible, behaviour but there are lots of similar examples in PHP

So true.

One I ran into recently was comparing hashes that start with '0e' and contain only a numeric component after that prefix. Failure to use the identity operator means that you can have two different hashes returning... equality. PHP apparently thought it a good idea to coerce that into 0 raised to an exponent, which of course always yields zero. e.g.:

    php > var_dump('0e41235843934' == '0e61193475532');
    bool(true)
Yeah, I know: The correct (and only) way to write this is to use the identity operator (===) but it's not at all intuitive. For those of us who are used to this it's fine since it's a force of habit, but for those who aren't it'll lead to unexpected behaviors. The only saving grace is that the quality of PHP code out there has been slowly (slowly!) improving over time, thanks in part to composer and ecosystem/cultural changes.

But it's also not outside the realm of possibility that someone won't eventually forget to add an extra '=' and induce a very difficult bug to isolate...

Re: PHP 8

#127

Post by pbowyer »

cstuder wrote: post #4

Apparently some of the deprecations will make this the most backward compatibility breaking version jump of PHP since V4 to V5. (Read a german interview here: https://www.heise.de/news/PHP-8-im-Experten-Check-Der-erwart... ) There's a long report on Wordpress and PHP 8 and it's not pretty: https://developer.yoast.com/blog/the-2020-wordpress-and-php-...

WordPress core team members and users are welcome to get involved in PHP development and providing feedback on proposals.

They are notably absent, and so people who write modern PHP - or wish PHP was a different language - are the ones influencing language development.

Re: PHP 8

#128

Post by muglug »

Kluny wrote: post #106
muglug wrote: post #8

Earlier quoted context omitted.

> There's a long report on Wordpress and PHP 8 and it's not pretty This is an awkward side-effect of WordPress core team largely neglecting PHP code quality issues for the last decade or so. With good reason – improving such a large codebase is a massive, mostly-thankless task.

I worked at WordPress for half a year, and I'm no expert, but the code reviews there were more intense than any I've ever experienced. Every line of code gets reviewed before it gets committed, and if the commit is longer than 20 lines or so, it undergoes an additional scheduled review as well as pre-commit review. They also have pretty good code sniffers that ought to catch errors like OP mentioned. The reason they'…

> WordPress has always been huge on backward compatibility.

Yes, and I think that's ultimately the root of its challenges.

A fear of breaking things means WP shies away from large-scale changes that would help it become a modern-looking PHP app.

I wrote this two years ago, and WordPress's basic architecture hasn't changed since: https://medium.com/@muglug/improving-wordpress-with-static-a...

Re: PHP 8

#129

Post by electrotype »

I haven't touched PHP for a long time now. How is the Unicode support now? I remember having to use some special utilities to handle characters like "œ" properly.

Re: PHP 8

#130

Post by Denvercoder9 »

ComputerGuru wrote: post #27
nolok wrote: post #19

Earlier quoted context omitted.

Reading the list of things that worry them makes it clear that it's not so much php is breaking bc than it is wordpress lack of cleaning and linting for so long catching up to them. I mean seriously the first thing they list as a worry is that arithmetic operators will now throw an error when one (and only one) of their operand is an array or resource (eg array + array support remains, it's really int + array or stri…

> This is literally a case that makes no sense in the code ever, Speaking as someone that hates PHP but still appreciates that it has its uses: You’re speaking from one perspective. There are others. That operation is perfectly valid and well-defined in Matlab where it increments all members of the matrix/vector by the scalar.

But PHP didn't do that, it just silently ignored the operation or returned zero. That behaviour doesn't make any sense.
Post reply on HN