чт, 8 авг. 2019 г. в 17:42, Chase Peeler <chasepee...@gmail.com>:
> > > On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks <arvids.godj...@gmail.com> > wrote: > >> чт, 8 авг. 2019 г. в 16:42, Peter Kokot <peterko...@gmail.com>: >> >>> Hello, >>> Thanks for sharing your stories about issues. Maybe we should start >>> also thinking about the impact on the language attractiveness to pick >>> it when starting a new web project since the core people can't come to >>> conclusions how to make the language more consistent on the long run >>> (PHP 9 etc)... With more and more ambiguities, inconsistencies, >>> lockups, and dead ends behind the language there is probably also a >>> bit of a factor to consider that it lowers this attractiveness. >>> Meaning less people will think of adopting it (with all the things >>> combined - short tags, that and that inconsistency not being removed >>> from PHP due to major disastrous BC break there and there). So, the >>> damage is also on the long run with more and more locks and dead ends >>> not being able to be fixed and cleaned. >>> >>> >>> -- >>> Peter Kokot >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> Hello. >> >> Peter above put my thoughts perfectly. >> >> BC is great, but you need to pull the cord at some point. And the whole >> short tag back and forth, with deprecation warning and stuff, has been >> around for last half a decade. It is time to accept that it needs to go and >> there should be no runtime dependent switch for this. Valid PHP tags are >> `<?php` and `<?=` and that's it. >> I really liked how language picked up the cleanup pace in the last few >> years and it needs it. I finally see genuine interest in people to actually >> either come back or pick it up instead of JavaScript (NodeJS) and other >> fancy new shiny stuff. And a lot of it is because of the cleanup efforts >> and WTF?! removal, the language having the option to be stricter (I was not >> a fan of strict mode when it was coming up - now I don't use anything else >> - it is AWESOME). >> If the old guard starts to push back as much as I have seen here, we are >> going to lose momentum as a community and have people not willing to work >> on PHP as much. I mean anyone who has been on this list for more than 10 >> years should remember how it was in 5.0-5.4 days - slow, painful and >> somewhat unfriendly, until a few major contributors kind'a muddled though >> and pushed a few major changes that allowed the momentum to build up and >> somewhat break the stalemate (and it did help that HHVM reared it's head >> and had stroked a few egos the wrong way). I guess the curve repeats >> itself, but we should make an effort to curb it and not revert back to "BC, >> BC, BC!!!!" holding everything up. >> >> Wait, how could positive progress have been made while short tags still > existed? > > >> Reality is, a lot of those "non-tech company" examples people give here >> has nothing to do with language evolution. Yes, they are users, but we are >> not responsible for the code they write, for the way they configure their >> web servers and the way they can run a PHP4 server past 10 years and still >> have no clue, because nobody cares or "it works, it makes money, no need to >> invest". I would say that most of us on this list, if not everyone, are >> smart enough to run/leave/not work for companies like that, so we are >> somewhat shielded from that ignorance and just forget how bad it can be. >> >> Long story short - indecision is not an option. The previous RFC has >> passed. Everyone involved, I hope, understands that yes, there will be >> stuff going wrong for some users who are careless and/or ignorant and live >> under a rock. Can we really do anything about that? I would say no unless >> we freeze the language and do nothing. I mean I have exposed my PHP code >> during server setup by just forgetting to do `systemctl reload nginx`, >> hitting the URL and getting my `index.php` on the screen more times than I >> care to confess to. >> > You're in the "all or nothing" logical fallacy. You are acting as if being > against the removal of short tags is the same as being against any BC break > at all. As we've said MANY times, BC breaks aren't the issue. THIS > PARTICULAR BC BREAK IS THE ISSUE. It provides little to no positives to the > users and does very little, if anything, to improve the language. At the > same time it WILL lead to a very big barrier in terms of the ability to > upgrade for a large number of users. > The RFC's both covered the fact that there is no good way to deprecate and remove short tags cleanly. Whatever road you take - it is going to result in issues for some users. The crux here is not the tags themselves per-se, but the engine level switch that changes the functionality of how the code is parsed. I mean if push comes to shove and people really really really do not want to remove `<?` to a point of using veto rights or pulling their weight or whatever can happen - leave them in (though I'm strongly against that), but the runtime switch needs to go. > > >> Let's look into the future, use a reasonable amount of caution and/or >> deprecation notice periods, but please stop trying to block features >> "because stupid users". You give them the most secure software you can >> write, they go change settings on their own and get p0wned/defaced/hacked >> anyway even when you tell them not to do it and that y'r refusing to work >> on their project because of decisions they make. >> >> Actually, most BC breaks, including this one, seem to be focused on > preventing issues from "stupid users." We're saying that short tags are bad > because of reasons. We can't trust users to not use short tags as long as > they exist, so we must force them to stop using them, no matter how painful > that might be. That's actually an OK thing to do if the reasons for doing > so justify it. I have yet to see the justification. All I've seen is people > attempt to mitigate the cost of the break, or, say the cost doesn't really > matter. > Because it is a runtime switch that affects how the engine works. It has been agreed years ago that they need to go like `register_globals` and a few others have been removed with time. This is the same category. It is language and engine cleanup. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
