Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106423 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 77466 invoked from network); 7 Aug 2019 22:18:14 -0000 Received: from unknown (HELO forward101p.mail.yandex.net) (77.88.28.101) by pb1.pair.com with SMTP; 7 Aug 2019 22:18:14 -0000 Received: from mxback10o.mail.yandex.net (mxback10o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::24]) by forward101p.mail.yandex.net (Yandex) with ESMTP id 34B45328039D; Wed, 7 Aug 2019 22:45:11 +0300 (MSK) Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback10o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id dOVS0bb7cq-jAT0NwJD; Wed, 07 Aug 2019 22:45:11 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=s-panteleev.ru; s=mail; t=1565207111; bh=mmfxu1GIjZsWrN/BAyMs9/0SPlOnr9QG4OmOHTvhb0M=; h=Subject:In-Reply-To:Cc:To:From:References:Date:Message-ID; b=ed9BF8Vgwhl9dtZnaMA9H8FHF5WHaFjPDuGRBszbalYsd5tGa/3Py1kQetZnaIY+2 99BJFjNTrb/DBIWaLSyhqBrkQQB0qJR/CR2KkR+NQAH/XyvTUbT174M/phwA5x5ZGC Qmu0oVz/3kXfUglgo69vrCoAjlik2Vlkw9Xbf6pU= Authentication-Results: mxback10o.mail.yandex.net; dkim=pass header.i=@s-panteleev.ru Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id dBvaS09F9o-j9HqZgKV; Wed, 07 Aug 2019 22:45:10 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Date: Wed, 7 Aug 2019 22:45:03 +0300 To: Peter Kokot , Zeev Suraski Cc: Chase Peeler , Dan Ackroyd , Andrey Andreev , "G. P. B." , PHP internals Message-ID: In-Reply-To: References: X-Readdle-Message-ID: be014a00-6965-4199-8604-604941095b08@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5d4b2a45_507ed7ab_66e6" Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again From: sergey@s-panteleev.ru (Sergey Panteleev) --5d4b2a45_507ed7ab_66e6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi there=21 Perhaps I missed and someone already suggested, but didn't consider a compromise option: just change the default value short=5Fopen=5Ftag=3Dfalse, and DON'T removes the option from php.ini=3F If someone uses short tags - ok, they will change the default value to true and everything will be as before, who won't change it - will enjoy the full syntax =E2=80=94 Sincerely, Sergey Panteleev https://s-panteleev.ru Phone: +7 (906) 634-79-37 Telegram: =40saundefined E-mail: sergey=40s-panteleev.ru On 7 Aug 2019, 22:25 +0300, Zeev Suraski , wrote: > On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot wro= te: > > > Considering that you're in favor of keeping the short opening tag in > > > PHP =22forever=22 because you haven't added any kind of other solution > > either by now neither you see an issue with this... I think the worst= > > situation for language is that there is an option to write non > > portable code with this unfortunate short tag. > > > Peter, > > To put it simply - many of us simply don't see an issue if short tags a= re > with us even at PHP 99, centuries after we're no longer around. We > certainly don't see an issue if it sticks with us until PHP 10. > > In fact, it's not that we don't think it's an issue - we actually think= > that's a Good Thing if it stays, and a Bad Thing if it's removed. > > I did my best to illustrate why I think that is the case in my > Counterargument ( > https://wiki.php.net/rfc/counterargument/deprecate=5Fphp=5Fshort=5Ftags= ). I > accept that you see things differently. However, please accept that we > also see things differently and are entitled to our opinion just as muc= h as > you are entitled to yours. We simply fail to see an issue with short ta= gs > that comes even close for us to want to remove it. It's not even a clos= e > call. A zero gain and substantial pain associated with a deprecation > should be an obvious choice. > > To quote Sara Golemon: > =22=46rankly, I can't understand why anyone *does* want to drop it.=22 > (https://twitter.com/SaraMG/status/1158936328450576384) > > PHP always had a bias for downwards compatibility. We went out of our w= ay > to come up with creative ways to reinvent the brain of the language sev= eral > times - while going through hoops to keep code behavior identical. We d= id > not shy away from breaking compatibility when there was a very strong c= ase > - such as the OO model between PHP 4 and 5, the deprecation of magic qu= otes > and the deprecation of safe mode - all painful migrations, but with a v= ery, > very strong case that goes well beyond =22having more than one way of d= oing > things=22 or =22this creates the possibility of non-portable code=22. T= BH, I > expected folks who are joining the project to accept that, although I g= uess > I was naive as this is clearly not happening (it's only implied in the > 'rules', but not actually codified). > > Repeating what I said a couple of weeks ago - it seems we've now switch= ed > to the business of breaking things almost for the sake of breaking thin= gs, > and it's really disheartening. > > Many of us think that removing short tags does *absolutely nothing* to > improve the portability of PHP code. > > I'll go beyond that - the ability to create non-portable code should ne= ver > be grounds by itself for deprecating a feature (it can be a contributin= g > factor). There are endless elements that an app can use that can make i= t > non portable. =46or example, should we be deprecating support for all > databases other than SQLite=3F After all, they may not always be instal= led. > Should we deprecate the SHM extension=3F People using it may be stuck i= f > they ever try to deploy to Windows. What about deprecating > disable=5Ffunctions=3F It's a portability disaster that's just waiting = to > happen. And I barely even got started. Almost anything beyond pure PHP > logic may not work in all environments, and it's absolutely fine. It al= so > constitutes absolutely no grounds for starting to go around axing featu= res. > > Thankfully, fact is, not all code has to be portable. The important thi= ng > is that those who want to write portable code will be able to do so - w= hile > not forcing everyone else to write portable code by enforcing the lowes= t > common denominator. > I think Chase alluded to the fact that there's substantial anecdotal > evidence that the availability of short tags did not actually cause any= > trouble in the last 20 years. And when I say anecdotal evidence - I mea= n > that some of the most popular applications on the Web (including the to= p 3 > most popular ones) have been written in PHP, and there's a gigantic > framework ecosystem around PHP. > > I realize that you think it's a problem that we have two opening tags f= or > PHP - and a major one at that. It's entirely your right to do so and I > wholeheartedly accept it. Similarly, please accept it that I, as well a= s > many others, simply don't view this as a problem. And when one does not= > think there's a problem, one typically does not spend time finding > solutions. > > =46WIW, if for whatever reason I did think it was a problem - I think t= he > updated V2 R=46C would be the best way to solve it. But I don't. > > With all that said, I still think there may be a solution that can make= > mostly everyone happy, or at least not really unhappy. It may even incl= ude > deprecating short tags (in a way) - but more importantly - overhauling = much > more important elements in PHP as well. I hope to bring it up for some > initial brainstorming (not R=46C level, just gauging response) tomorrow= . > > Zeev --5d4b2a45_507ed7ab_66e6--