Hi Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler <chasepee...@gmail.com>: > You going to come and fix the issues? It's an internal application and > most of those messages are coming from legacy areas of the code which are > mainly "it works, so leave it alone" things. Instead of going back and > spending time trying to fix those boondoggles, we invest the time of our > developers (there are 2 others besides myself) into building new features > that help our business grow. Time permitting, we try and update some of the > legacy areas, but, we usually find it's a better investment to just rebuild > them at that point. > > Bottom line is that we live with the not-so-good stuff so that we can focus > on adding new great stuff. The not-so-good stuff isn't holding us back, and > trying to fix things like undeclared variables would have absolutely ZERO > positive effect on our business, which uses this application every day. If > I went to our executive team and said "Can we delay that new scheduling > system that will really help our business so I can go back and update code > to get rid of these undeclared variable notices?" I'd get laughed at! > > Like I've said before - can we please stop pretending we understand > everyone else's situation? Maybe my situation is unique. My gut tells me it > might be unique among people on this list, but, that it's actually pretty > common among the myriad of developers out there which never get involved in > these discussions.
I'm sorry, but like Mark Randall has already pointed out then this is a classic example of technical depth. At one point you must choose, "Do I want to upgrade to the latest version of PHP or do I want to fix the issues which is caused by the technical depth in my stack?". I get it, writing new code is always more fun, it really is, I have previously worked with companies with that same attitude that "we'll fix it later", but at one point that becomes such a burden and if your management doesn't believe in putting in resources to actual maintenance of your infrastructure, then I'm sorry but it does not sound like a healthy place to be (no offense meant). Right now your argument is merely trying to hold back changes which will bite that technical depth of yours, and everytime an argument has been raised towards your concerns it has been met with "Will you come and fix it?", "I demand that X, Y or Z tool is available for me to use", etc., so again, I'm sorry but I'm not buying this argument. Some things we can solve by an opt-in, like the strict_types declare, however other things so fundamental to the language should not have any options to alter its behavior, that should be consistent. We have spend a long time trying to carve a migration path and advocate against options which changes language behavior across installations. If we continue down this path, then its just a runtime version of php.ini with a million declare statements on top of each file, each having multiple meanings and an added complexity to maintain the code, not a burden I think userland developers need as it is. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
