Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106427 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 98384 invoked from network); 8 Aug 2019 00:12:57 -0000 Received: from unknown (HELO mail-ot1-f54.google.com) (209.85.210.54) by pb1.pair.com with SMTP; 8 Aug 2019 00:12:57 -0000 Received: by mail-ot1-f54.google.com with SMTP id r6so110276589oti.3 for ; Wed, 07 Aug 2019 14:39:57 -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:content-transfer-encoding; bh=BOkg6vYOt4p7hmglrUBHpbh/RqcNT7US9297HP2lojY=; b=jAMAHkFlxrDfkfjlqayjv9e+R45FOQp8n1oae5nMBIc4GKa3QndARxVIpCUYlZZxUe w6pkUa9/SwIWY1E+OTdc1gqj5hG62ipErCUbRzZDpOZ7MstKDWC9hvOR6O26KbaWJb7q N8DbRUSsOHBCG4Rr+WHPnBWwPX31NgfhLkTZh0MnwGhyqn+cGoME7ULAm24dKMQFE4Wi IdSMlXNv00dk5XSv9iwfvNxOfLsP9ofARK8HKuUEC93k7SRMQB3Yjt7A3Bff5bb98r82 BjEQCDDfgIHHWyItG39ENHacM8ZQeTAV7meqGl5FTVpyoQ0/dBi9LmSD5z77uQGzW6Ds 0WPQ== 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:content-transfer-encoding; bh=BOkg6vYOt4p7hmglrUBHpbh/RqcNT7US9297HP2lojY=; b=LLgRCoo4FFjRvCd0ReDaH5eNyREWyuEyK1q9SwFxEbiWw6yQePaJslLUenywlnTXgk 4udzBpJ213ayISd5yu6qX5QqwRSOyzulYq1Ky9eRCc4gdo6LSMOMMtNZlj0ofsEVk+tw 25HxhR0ANwhaKidPAzj6HeHUHjG9PhfabX4fI4Ai0rGd4lu9aZWai7EhkFGL1bf2XXH2 iXCa+lP9EK6SHTGQVz4elIqLoBg+guMLPB/ffQwgeClXRuOBEIZ43z2rVypSb4TMIeO/ kxKeVkw2AivfgIRsR6NfvIPK2h8ciRyl61b+/CWUqOa+rd212q4c05Ohcxpo4icqcxYl SwUw== X-Gm-Message-State: APjAAAWxRuofGdaX1s6RzS3P0Y0BsGfNdk9EJ4zXeUMiTyGnQqQwkkyg 1UvrafCEOFyqlZxD5nsXJErBKYRfrthg+sreHFo= X-Google-Smtp-Source: APXvYqzKK3+DofDhYicRAOkIORHGWa4pOg4rTVEn9m6144OKHuTyLNLxzxPUv0d9fF32Rs191PRYqywbFLk8aGZkNpA= X-Received: by 2002:a9d:a76:: with SMTP id 109mr8980556otg.252.1565213996481; Wed, 07 Aug 2019 14:39:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 7 Aug 2019 23:39:44 +0200 Message-ID: To: Zeev Suraski Cc: Chase Peeler , Dan Ackroyd , Andrey Andreev , "G. P. B." , PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again From: peterkokot@gmail.com (Peter Kokot) On Wed, 7 Aug 2019 at 21:25, Zeev Suraski wrote: > > > > On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot wrote: >> >> Considering that you're in favor of keeping the short opening tag in >> >> PHP "forever" 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 are= with us even at PHP 99, centuries after we're no longer around. We certai= nly 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 t= hat'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 Counterarg= ument (https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags). = I accept that you see things differently. However, please accept that we = also see things differently and are entitled to our opinion just as much as= you are entitled to yours. We simply fail to see an issue with short tags= that comes even close for us to want to remove it. It's not even a close = call. A zero gain and substantial pain associated with a deprecation shoul= d be an obvious choice. > > To quote Sara Golemon: > "Frankly, I can't understand why anyone *does* want to drop it." > (https://twitter.com/SaraMG/status/1158936328450576384) > > PHP always had a bias for downwards compatibility. We went out of our wa= y to come up with creative ways to reinvent the brain of the language sever= al 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 ca= se - such as the OO model between PHP 4 and 5, the deprecation of magic quo= tes and the deprecation of safe mode - all painful migrations, but with a v= ery, very strong case that goes well beyond "having more than one way of do= ing things" or "this creates the possibility of non-portable code". TBH, I= expected folks who are joining the project to accept that, although I gues= s I was naive as this is clearly not happening (it's only implied in the 'r= ules', but not actually codified). > > Repeating what I said a couple of weeks ago - it seems we've now switched= to the business of breaking things almost for the sake of breaking things,= and it's really disheartening. > > Many of us think that removing short tags does absolutely nothing to impr= ove the portability of PHP code. > > I'll go beyond that - the ability to create non-portable code should neve= r be grounds by itself for deprecating a feature (it can be a contributing = factor). There are endless elements that an app can use that can make it n= on portable. For example, should we be deprecating support for all databas= es other than SQLite? After all, they may not always be installed. Should= we deprecate the SHM extension? People using it may be stuck if they ever= try to deploy to Windows. What about deprecating disable_functions? It's= a portability disaster that's just waiting to happen. And I barely even g= ot started. Almost anything beyond pure PHP logic may not work in all envi= ronments, and it's absolutely fine. It also constitutes absolutely no grou= nds for starting to go around axing features. > > Thankfully, fact is, not all code has to be portable. The important thin= g is that those who want to write portable code will be able to do so - whi= le not forcing everyone else to write portable code by enforcing the lowest= common denominator. > I think Chase alluded to the fact that there's substantial anecdotal evid= ence that the availability of short tags did not actually cause any trouble= in the last 20 years. And when I say anecdotal evidence - I mean that som= e of the most popular applications on the Web (including the top 3 most pop= ular ones) have been written in PHP, and there's a gigantic framework ecosy= stem around PHP. > > I realize that you think it's a problem that we have two opening tags for= PHP - and a major one at that. It's entirely your right to do so and I wh= oleheartedly accept it. Similarly, please accept it that I, as well as man= y 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. > > FWIW, if for whatever reason I did think it was a problem - I think the u= pdated V2 RFC 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 m= ostly everyone happy, or at least not really unhappy. It may even include = 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 in= itial brainstorming (not RFC level, just gauging response) tomorrow. > > Zeev > Thank you for such a detailed response. Ok, I understand then. Then next logical step here is - I would maybe want to use these awesome short tags also then. They are shorter, which I like, templates look a bit more decent and aligned and all that what some have pointed out... So, why not enabling these short tags everywhere then and suggesting in the PHP manual that they can be used again in PHP x.y version etc? This is from the contributors point of view somehow I think a logical step forward - someone who sees there is something semi-working and possibly could be working everywhere without BC break issues so they want to fix this functionality as it could be fixed. Enabling these tags back (or enabling them for the first time everywhere without option to be disabled) is also a good thing according to all this. Yes? Because otherwise, I think it is a bit broken functionality by design if it causes so much issues to be removed and at the same time many people want to have it in PHP forever here... --=20 Peter Kokot