Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106448 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 83886 invoked from network); 8 Aug 2019 19:09:13 -0000 Received: from unknown (HELO mail-wr1-f51.google.com) (209.85.221.51) by pb1.pair.com with SMTP; 8 Aug 2019 19:09:13 -0000 Received: by mail-wr1-f51.google.com with SMTP id 31so95611442wrm.1 for ; Thu, 08 Aug 2019 09:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z5ogHB4Y3Y4ZPRDjYFwBAlkvIl9XXC89r/GZKpCIi00=; b=TAPZ9Ep1bmqlKg/7x2n1h7Ooz7gnOwYNhbiKmf8pRs5u81rduw6nQ1UxpxntWZPe51 cyXuIbAR1HjakkdzSSsyldUDRy3/BWWYXxa0h7ephnypzecG1Gub2/oyfcficVR3zS9p K7+PfTFAofhdTxQBe2QtzBDut+5WgQbMBiatCQ8sERSSpaNgiXDjLs8FF7iCk0pXY39/ nxmLtB6AjpiPfjuDrUSB7YJEACtCR+DdWeaKes3LXU6zXthOg4H59mnXjgH7IugNPfFD 1slBTXt4Y3V5Y86Or9/34+PtoFOTX5ro5RlkYd5aEgZqdUAuHnYOg1PmKnQmtSSbW9pX iZXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z5ogHB4Y3Y4ZPRDjYFwBAlkvIl9XXC89r/GZKpCIi00=; b=hHAP2g+P3CsbFQ6bKLeeiJ0xpPtr8RCkQph7zco4O5gAKuSnInauosmRtHgbu9DR0f DQYzWm4yAgC+6UkeMDpH+dA1ezo/szaDPXtm0OPuD4HL3bENYFI7dgRbYSuQ+DBckszT iSGD/lDNKMalrikI3ca5gqt/DMdBM/pxRIvXWQY1rqJUp8INT9HLsxYTdBJ4Ia6HEq60 AKufpNQMlXZe6y4hRR27v29QEc/jDiT2O/r86KUHcYz8qzsIjnDgZiJ7e+7ZJ09bMuXZ ORz8ase0obXerRTA1yDwN1dI/cr8clOGE8a3gEa2A6L9A85m9dJ23ZoTuujX7MtsY76k XFYA== X-Gm-Message-State: APjAAAWlTwxQERLboEMgCosPczvVm+wtpPmpz9tjZ7E4A6NDmLtrDVD0 Nilk7NBZiyMNOe+0Jo3K+h0caxvhhx85vFcxRLE= X-Google-Smtp-Source: APXvYqzWPnA4UiHW+WUBUL7W0Pi46dy+HdJdPxUU5UdQp3AOsRRZ2UdVGMFx5Gw79YVyf4VwCFNT+jr8izUl37vT9P4= X-Received: by 2002:adf:e343:: with SMTP id n3mr18565961wrj.103.1565282183904; Thu, 08 Aug 2019 09:36:23 -0700 (PDT) MIME-Version: 1.0 References: <1759114.DMe9nKvMbn@mcmic-probook> <62c73b8f-df41-43c2-bb51-ceeaf607cacf@Spark> In-Reply-To: Date: Thu, 8 Aug 2019 18:35:57 +0200 Message-ID: To: Chase Peeler Cc: Peter Kokot , Zeev Suraski , Brent , Internals , =?UTF-8?Q?C=C3=B4me_Chilliet?= Content-Type: multipart/alternative; boundary="0000000000008b8355058f9da8b0" Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again From: arvids.godjuks@gmail.com (Arvids Godjuks) --0000000000008b8355058f9da8b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=87=D1=82, 8 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 17:42, Chase Peeler= : > > > On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks > wrote: > >> =D1=87=D1=82, 8 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 16:42, Peter Kok= ot : >> >>> 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 >> `> 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 actua= lly >> 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 el= se >> - 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 wor= k >> 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 thoug= h >> 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 a= re >> not responsible for the code they write, for the way they configure thei= r >> web servers and the way they can run a PHP4 server past 10 years and sti= ll >> 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 li= ve >> under a rock. Can we really do anything about that? I would say no unles= s >> 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 bein= g > against the removal of short tags is the same as being against any BC bre= ak > 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 t= he > 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 ` > >> 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/hacke= d >> anyway even when you tell them not to do it and that y'r refusing to wor= k >> 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 b= ad > 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 painf= ul > 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 peop= le > attempt to mitigate the cost of the break, or, say the cost doesn't reall= y > 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. --=20 Arv=C4=ABds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius --0000000000008b8355058f9da8b0--