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

Upcoming Hardening in PHP

dustri.org

Post reply on HN
Print view View original

21–30 of 130 posts

Re: Upcoming Hardening in PHP

#21

Post by hparadiz »

that_guy_iain wrote: post #20
ipaddr wrote: post #18

Earlier quoted context omitted.

Historically they have been one of the languages that added very few breaking changes and were criticized for that. You can't have it both ways. Going from php 4 to php 8 isn't even that painful and there are twenty years between. It's the one language where what you wrote 20 years ago probably still works today. Upgrading a php application is one of the least expensive and uneventful things you can do. Try upgrading…

My complaint was adding lots of breaking changes to minor version upgrades. The fact, that historically they didn’t do breaking changes in major version upgrades does not excuse going against industry standards. There are literally companies stuck on PHP 7 because going to 8 is too painful. And honestly with my decade of experience your claim that going from 4 to 8 isn’t that painful sounds like nonsense and somethin…

Like everything... It depends.

Just use rector

https://github.com/rectorphp/rector

Re: Upcoming Hardening in PHP

#22

Post by that_guy_iain »

hparadiz wrote: post #21
that_guy_iain wrote: post #20

Earlier quoted context omitted.

My complaint was adding lots of breaking changes to minor version upgrades. The fact, that historically they didn’t do breaking changes in major version upgrades does not excuse going against industry standards. There are literally companies stuck on PHP 7 because going to 8 is too painful. And honestly with my decade of experience your claim that going from 4 to 8 isn’t that painful sounds like nonsense and somethin…

Like everything... It depends. Just use rector https://github.com/rectorphp/rector

I've previously used that to do something. Fell flat on its face. But the fact they literally had to create a tool to solve this problem confirms my point.

Re: Upcoming Hardening in PHP

#24

Post by p4bl0 »

Something I'd really like is for PHP to somehow be stricter on the number of arguments passed to a function.

As of now, PHP emits an error if arguments are missing but not if there are too many.

A way to bake that in without breaking old code would be to allow function definition to put an explicit stop to the argument list, for example using the void type keyword:

    function foo (int $a, string $b, void) : bool
    { ... }
A few month ago I discussed this on the development mailing list and people seemed to agree and even suggested that this would be a good idea by default without the keyword thing I suggested. But I never got the time to properly write an RFC. There is already an old one from years ago that was voted against but In was told it was from before anything strict and typing related was considered important in PHP. If anyone's up to it, please write this RFC :) !

Re: Upcoming Hardening in PHP

#25

Post by kortilla »

bigtimesink wrote: post #23
justinclift wrote: post #6

> Suggestion to make those parts read-only was rejected as a 0.6% performance impact was deemed too expensive for too little gain. Big Oof. :( :( :(

At a large PHP shop, 0.6% can be tens of millions of dollars.

Over what time period? You’re implying they are spending at least a billion dollars on hardware costs for 0.6% to be tens of millions.

Re: Upcoming Hardening in PHP

#26

Post by chx »

that_guy_iain wrote: post #20
ipaddr wrote: post #18

Earlier quoted context omitted.

Historically they have been one of the languages that added very few breaking changes and were criticized for that. You can't have it both ways. Going from php 4 to php 8 isn't even that painful and there are twenty years between. It's the one language where what you wrote 20 years ago probably still works today. Upgrading a php application is one of the least expensive and uneventful things you can do. Try upgrading…

My complaint was adding lots of breaking changes to minor version upgrades. The fact, that historically they didn’t do breaking changes in major version upgrades does not excuse going against industry standards. There are literally companies stuck on PHP 7 because going to 8 is too painful. And honestly with my decade of experience your claim that going from 4 to 8 isn’t that painful sounds like nonsense and somethin…

You are right, going from 4 to 8 is a huge challenge.

Minor point: classes are using the same syntax but you are right they typically won't work because the constructor have changed, in PHP4 it was a function named the same as the class, in PHP5 and on it's __construct, the PHP4 version was deprecated in PHP 7 and removed in PHP 8.0.

create_function is just gone. So is each(). Oh and HTTP_RAW_POST_DATA. The list is long.

If you have used == and in PHP4 we did that, come on, don't be holier than holy and claim you only used === in PHP4 then PHP8 will have some surprises for you.

In my experience rector became usable last year-ish, if you tried before, give it another whirl.

Re: Upcoming Hardening in PHP

#27

Post by hparadiz »

that_guy_iain wrote: post #22
hparadiz wrote: post #21

Earlier quoted context omitted.

Like everything... It depends. Just use rector https://github.com/rectorphp/rector

I've previously used that to do something. Fell flat on its face. But the fact they literally had to create a tool to solve this problem confirms my point.

I use it all the time and it works great. You need to know what you're doing.

Re: Upcoming Hardening in PHP

#28

Post by MH15 »

p4bl0 wrote: post #24

Something I'd really like is for PHP to somehow be stricter on the number of arguments passed to a function. As of now, PHP emits an error if arguments are missing but not if there are too many. A way to bake that in without breaking old code would be to allow function definition to put an explicit stop to the argument list, for example using the void type keyword: function foo (int $a, string $b, void) : bool { ...…

I'd be curious to read about what percentage of active PHP devs use the recent features. The last time I worked in a PHP codebase (2020?) was half PHP 5 (bad) and half PHP 7 (much nicer). Curious if there's any real info out there on this

Re: Upcoming Hardening in PHP

#29

Post by zuppy »

MH15 wrote: post #28
p4bl0 wrote: post #24

Something I'd really like is for PHP to somehow be stricter on the number of arguments passed to a function. As of now, PHP emits an error if arguments are missing but not if there are too many. A way to bake that in without breaking old code would be to allow function definition to put an explicit stop to the argument list, for example using the void type keyword: function foo (int $a, string $b, void) : bool { ...…

I'd be curious to read about what percentage of active PHP devs use the recent features. The last time I worked in a PHP codebase (2020?) was half PHP 5 (bad) and half PHP 7 (much nicer). Curious if there's any real info out there on this

php 7 has been released 9 years ago.

Re: Upcoming Hardening in PHP

#30

Post by withinboredom »

p4bl0 wrote: post #24

Something I'd really like is for PHP to somehow be stricter on the number of arguments passed to a function. As of now, PHP emits an error if arguments are missing but not if there are too many. A way to bake that in without breaking old code would be to allow function definition to put an explicit stop to the argument list, for example using the void type keyword: function foo (int $a, string $b, void) : bool { ...…

I don’t really understand the issue. Already if you have a mismatch, the only way you’d ever know is through static analysis. It will run and maybe crash during run time. I always joke that changing a function signature is the single most risky thing you can do in php (especially if you have any dynamic dispatch). Making it even more risky isn’t the right answer, IMHO.

Oh, and doing this would literally break class autoloading in symfony, and even the engine itself, which relies on this feature.

Post reply on HN