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. > 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. > -- > Arvīds Godjuks > > +371 26 851 664 > arvids.godj...@gmail.com > Skype: psihius > Telegram: @psihius https://t.me/psihius > -- Chase Peeler chasepee...@gmail.com
