Re: [PHP-DEV] [RFC] Reclassifying engine warnings

  106727
August 28, 2019 14:11 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald reindl@thelounge.net>
wrote:

> > > Am 28.08.19 um 15:48 schrieb Chase Peeler: > > If it is still done, then I think a deprecation path is a must. As > > mentioned earlier, this doesn't necessarily mean E_DEPRECATION messages - > > warnings will work too. The key is that error logs with more urgency than > > notices are created that users can use to track down and fix issues. > > hell, there are notices for at least a decade > > error_log = "/var/log/php_error.log" > error_reporting = E_ALL > display_errors = 1 > > this is my development *as well* production config on every machine > since 16 years now and every warning/notice get fixed because every 30 > minutes the errorlog get mailed to every developer and admin > > turn logging on and start cleanup what you would have had a decade time.
Am I the only one getting tired of people telling me how I need to operate just like they do? Everyone's circumstances are different. Just because something is easy for you, or works well for you, doesn't mean it's easy or even feasible for someone else. I've learned it's useless to try to explain how my situation might not be exactly like everyone else's, so I'm not going to waste the time doing it again. Why can't anyone see that taking on these myopic "My situation is the only valid situation" views are going to kill this language. "I always initialize my variables, so, it's no big deal if everyone else is forced to do so." "I was able to find and replace all the short tags in my code in 5 minutes, so it should be easy for everyone else to do as well." "We fix every single notice within 30 minutes of it popping up in a log. You should be able to do that as well." etc. etc. etc. Also, if you are going to try and tell me how I should my job, at least have the guts to reply to the entire list instead of sending it to me in a private reply. I'm obviously not afraid to turn around to make your reply public, so it'll save everyone a bit of time. -- Chase Peeler chasepeeler@gmail.com
  106728
August 28, 2019 14:15 chasepeeler@gmail.com (Chase Peeler)
Well, one reason I was so vocal about short tags wasn't a love for short
tags themselves. It wasn't even to prevent the detrimental effects of
removing them. Honestly, the 2nd RFC wasn't a horrible option. It was more
about the precedent that it set - pushing huge BC breaks on the users (most
of which are voiceless in the process, because they aren't involved in the
community at all, most not really aware there is anything to be involved
with) with little, if any, positive gain.

Let's see how this plays out a bit longer. It's too early to tell if it's a
dying attempt to keep pushing those type of changes, which are destined to
be rejected, or, evidence that we are still in danger of having such a
precedent set.



On Wed, Aug 28, 2019 at 10:11 AM Chase Peeler <chasepeeler@gmail.com> wrote:

> > > On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald reindl@thelounge.net> > wrote: > >> >> >> Am 28.08.19 um 15:48 schrieb Chase Peeler: >> > If it is still done, then I think a deprecation path is a must. As >> > mentioned earlier, this doesn't necessarily mean E_DEPRECATION messages >> - >> > warnings will work too. The key is that error logs with more urgency >> than >> > notices are created that users can use to track down and fix issues. >> >> hell, there are notices for at least a decade >> >> error_log = "/var/log/php_error.log" >> error_reporting = E_ALL >> display_errors = 1 >> >> this is my development *as well* production config on every machine >> since 16 years now and every warning/notice get fixed because every 30 >> minutes the errorlog get mailed to every developer and admin >> >> turn logging on and start cleanup what you would have had a decade time. > > > Am I the only one getting tired of people telling me how I need to operate > just like they do? Everyone's circumstances are different. Just because > something is easy for you, or works well for you, doesn't mean it's easy or > even feasible for someone else. I've learned it's useless to try to explain > how my situation might not be exactly like everyone else's, so I'm not > going to waste the time doing it again. > > Why can't anyone see that taking on these myopic "My situation is the only > valid situation" views are going to kill this language. > > "I always initialize my variables, so, it's no big deal if everyone else > is forced to do so." > "I was able to find and replace all the short tags in my code in 5 > minutes, so it should be easy for everyone else to do as well." > "We fix every single notice within 30 minutes of it popping up in a log. > You should be able to do that as well." > etc. etc. etc. > > Also, if you are going to try and tell me how I should my job, at least > have the guts to reply to the entire list instead of sending it to me in a > private reply. I'm obviously not afraid to turn around to make your reply > public, so it'll save everyone a bit of time. > > -- > Chase Peeler > chasepeeler@gmail.com >
-- Chase Peeler chasepeeler@gmail.com