Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105538 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 35596 invoked from network); 1 May 2019 05:19:41 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 1 May 2019 05:19:41 -0000 To: internals@lists.php.net References: <49A4B76C-4C62-4CBE-BA20-FBE56CA29AB0@cschneid.com> <609E93CF-099B-446C-AD28-04F1D802C9F0@cschneid.com> <000401d4fac8$ae592cf0$0b0b86d0$@roze.lv> <961cee8e-8185-b7b2-2b51-838946d2c7d2@gmail.com> Date: Wed, 1 May 2019 03:22:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 94.1.167.52 Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags From: markyr@gmail.com (Mark Randall) Message-ID: On 01/05/2019 01:19, Peter Kokot wrote: > I haven't seen code with short tags for such a long time now that this > is for me a problem on a scale of a fly. Because we've simply upgraded > all very very long time ago or in other words even never thought of > writing something in these tags anymore. I think it's important to remember that for every piece of actual code that's seen in the wild on the internet, there's likely a couple of orders of magnitude more that never leaves the proprietary servers / repositories of individual companies -- Code that has been written over a great many years that could always rely on short open tags being there because it's company code on company servers running php.inis configured by company staff. The code exposure is secondary IMO. I mean, it's certainly bad, but developers will be faced with a much more catastrophic issue to contend with, and that's the somewhat terrifying issue of logical control operations silently ceasing to exist. Super Secret: If people are so adamant about getting rid of it (as opposed to just making it always available) then I think Nikita needs to bring forward his proposals as an RFC with all due haste, as it's quite clear the current plan cannot go forward as-is. -- Mark Randall