I am not sure what to think about some of those changes, most likely I will quickly learn to love all of them except one - @ operator removal is unreasonable. I am completely serious about it.
I mean I get it, I can easily understand why using @ operator is a bad practice in predictable environments where absolutely nothing can go wrong... and by predictable environments I mean of course Apache/Nginx mods, PHP-FPM... Web in general.
I wonder if someone there forgot that PHP is a GENERAL-PURPOSE language and there are people, myself included, using it to build applications outside the realm of... Apache/Nginx mods, PHP-FPM... Yeah, web in general.
PHP 7 was huge for me, in my opinion for the first time in history it made PHP a viable option for something other than processing web templates, all of a sudden you could actually start using it for general-purpose and people didn't look at you like you were out of your mind.
So, why I make such a big deal about some silencer? Well, when you start to operate outside of (mentioned twice already) predictable environments and have to deal with completely unpredictable outcomes on daily basis you very quickly find out that some warnings and errors are unavoidable, but also that they do not always represent mistakes in your code or design, or even something that can or should be fixed. Lets be realistic - if something is bound to fail, crash and burn in one case of a thousand no matter what you do, and it doesn't actually crash and burn because you were wise enough to put that little @ in there... And you didn't actually "silenced" it because you actually bother to check if it failed or not... Am I the only one seeing it?
Silencing whatever I want, whenever I feel like it? Put a SINGLE-CHARACTER shut-op on extremely rare but unavoidable trouble maker and carry on? Sooo useful, sooo good, sooo nice and also... blazing fast. I mean I ran actual tests to see how it looks when compared to try {} catch {} "alternative". Putting aside how awful it looks in tight spots in code and how unpractical it is when trying to achieve exactly the same effect as with beloved SINGLE-CHARACTER, elegant @ shut-op - its so slow it can create a bottlenecks in certain spots. I mean it - don't ever try {} catch {} stream_select()/socket_select(), blocking or not, even when used with small number of sockets to track with almost no traffic on them. What happens when you put @ operator? It's like it wasn't even there. It works so well I actually never even bothered to check what makes it that efficient, and why would I?
Whatever genius came out with shut-op removal idea - where is he? Where are you mister master? Good sir? Could you please help me kind sir? Silly me, I got a little teensy-weensy confused here and I would be very grateful if you be so kind and generous to spare a moment of your precious time to help me discover how to properly handle scenarios without that diabolic evil @ operator - and there are many scenarios, and they vary...
Here is stupid little example - lets say I have daemonised long-running process, my process is handling couple signals, signals INTERRUPT all blocking operations, most blocking operations when interrupted will immediately litter my logs with useless warnings (interruption of blocking operations at signal arrival is EXPECTED BEHAVIOUR, why they even generate those warnings?!) but lets assume for a second that it doesn't bother me and I can live with that (in reality I don't) - some of them will not be so nice and instead of a warning will throw and error and flip entire process, how am I supposed to prevent it?
It this scenario there are only 3 things to keep in mind:
I don't want to put signal block mask before error-throwing troublemakers because its anti-pattern and it's beneficial for them to be immediately interrupted as signal needs to be handled ASAP.
I will not use try {} catch {} because it will create bottlenecks all over (also they are ugly af).
I still want everything else to throw an error when there is an actual error, because otherwise I wouldn't be able debug anything .
Let's hear it. I have like a dozen more complex scenarios at the top of my head - if that's what it takes to keep my little friend @ in this bug 8, then I can put them all inside some email and send that email whenever it needs to be sent. How about bribes?
What's the alternative then? If you don't suppress error you were not supposed to receive and cannot fix, then your process will crash when it's not supposed to.
Sorry, but PHP cannot have it both ways and still be described as reliable general-purpose language. It either has to provide stable, consistent behaviour and compliance with standards across all its core extensions OR provide developers with reliable tool to countermeasure.
PHP 7.4 provides reliable tool to countermeasure when core extension is acting out - that makes it a reliable, you can work with it, you can build things without taking personal risks to your career.
So far the only thing certain about PHP 8 is that it removes the tool to countermeasure that was needed in previous versions. What I would expect as a solution would be some kind of reassurance like "we are removing @ shut-op, but we also fixed the reason you needed it in the first place".
I am not sure what to think about some of those changes, most likely I will quickly learn to love all of them except one - @ operator removal is unreasonable. I am completely serious about it.
I mean I get it, I can easily understand why using @ operator is a bad practice in predictable environments where absolutely nothing can go wrong... and by predictable environments I mean of course Apache/Nginx mods, PHP-FPM... Web in general.
I wonder if someone there forgot that PHP is a GENERAL-PURPOSE language and there are people, myself included, using it to build applications outside the realm of... Apache/Nginx mods, PHP-FPM... Yeah, web in general.
PHP 7 was huge for me, in my opinion for the first time in history it made PHP a viable option for something other than processing web templates, all of a sudden you could actually start using it for general-purpose and people didn't look at you like you were out of your mind.
So, why I make such a big deal about some silencer? Well, when you start to operate outside of (mentioned twice already) predictable environments and have to deal with completely unpredictable outcomes on daily basis you very quickly find out that some warnings and errors are unavoidable, but also that they do not always represent mistakes in your code or design, or even something that can or should be fixed. Lets be realistic - if something is bound to fail, crash and burn in one case of a thousand no matter what you do, and it doesn't actually crash and burn because you were wise enough to put that little @ in there... And you didn't actually "silenced" it because you actually bother to check if it failed or not... Am I the only one seeing it?
Silencing whatever I want, whenever I feel like it? Put a SINGLE-CHARACTER shut-op on extremely rare but unavoidable trouble maker and carry on? Sooo useful, sooo good, sooo nice and also... blazing fast. I mean I ran actual tests to see how it looks when compared to try {} catch {} "alternative". Putting aside how awful it looks in tight spots in code and how unpractical it is when trying to achieve exactly the same effect as with beloved SINGLE-CHARACTER, elegant @ shut-op - its so slow it can create a bottlenecks in certain spots. I mean it - don't ever try {} catch {} stream_select()/socket_select(), blocking or not, even when used with small number of sockets to track with almost no traffic on them. What happens when you put @ operator? It's like it wasn't even there. It works so well I actually never even bothered to check what makes it that efficient, and why would I?
Whatever genius came out with shut-op removal idea - where is he? Where are you mister master? Good sir? Could you please help me kind sir? Silly me, I got a little teensy-weensy confused here and I would be very grateful if you be so kind and generous to spare a moment of your precious time to help me discover how to properly handle scenarios without that diabolic evil @ operator - and there are many scenarios, and they vary...
Here is stupid little example - lets say I have daemonised long-running process, my process is handling couple signals, signals INTERRUPT all blocking operations, most blocking operations when interrupted will immediately litter my logs with useless warnings (interruption of blocking operations at signal arrival is EXPECTED BEHAVIOUR, why they even generate those warnings?!) but lets assume for a second that it doesn't bother me and I can live with that (in reality I don't) - some of them will not be so nice and instead of a warning will throw and error and flip entire process, how am I supposed to prevent it?
It this scenario there are only 3 things to keep in mind:
Let's hear it. I have like a dozen more complex scenarios at the top of my head - if that's what it takes to keep my little friend @ in this bug 8, then I can put them all inside some email and send that email whenever it needs to be sent. How about bribes?
IMHO, @ is a terrible operator. Suppressing errors to make them go away is not something I would recommend in any case.
What's the alternative then? If you don't suppress error you were not supposed to receive and cannot fix, then your process will crash when it's not supposed to.
Sorry, but PHP cannot have it both ways and still be described as reliable general-purpose language. It either has to provide stable, consistent behaviour and compliance with standards across all its core extensions OR provide developers with reliable tool to countermeasure.
PHP 7.4 provides reliable tool to countermeasure when core extension is acting out - that makes it a reliable, you can work with it, you can build things without taking personal risks to your career.
So far the only thing certain about PHP 8 is that it removes the tool to countermeasure that was needed in previous versions. What I would expect as a solution would be some kind of reassurance like "we are removing @ shut-op, but we also fixed the reason you needed it in the first place".
See the big picture. This operator creates more problems than it solves.
display_errorsoff and logs seems a better choice.