Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105384
Return-Path: <markyr@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 41171 invoked from network); 24 Apr 2019 19:06:08 -0000
Received: from unknown (HELO localhost.localdomain) (76.75.200.58)
  by pb1.pair.com with SMTP; 24 Apr 2019 19:06:08 -0000
To: internals@lists.php.net
References: <CAFPFaMJEn=gjk5jAAxR2bF=4Mt3r0FJCm6mbOCReOmyybtAkkg@mail.gmail.com>
 <CAOv67gsiva80KEhw7D2N2qKCz0gZvza30EDL7SZoJRPFsGoROA@mail.gmail.com>
 <0ec42fa9-77d1-a203-8425-e72fdd5071f3@korulczyk.pl>
 <06473788-a34b-f041-36e6-31d19d8dda4c@cubiclesoft.com>
 <59cafbfb-2bb0-468c-458f-74bcac780e0f@korulczyk.pl>
 <004c01d4f09f$880ac320$98204960$@roze.lv>
 <CAFPFaM+QwXpm-mfwRtbT2sPB_C-9wvPELVTV5dHvizgmfUjMnw@mail.gmail.com>
 <004401d4faa3$60f83700$22e8a500$@gmail.com>
 <2f922f17-bc7c-313a-8f77-122e861995be@lsces.co.uk>
 <CAPKYkKyS4A_zQO3OEqqv+LOrG5cPLjGqUEXonsQeA_jcE=69Gg@mail.gmail.com>
Date: Wed, 24 Apr 2019 17:06:49 +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: <CAPKYkKyS4A_zQO3OEqqv+LOrG5cPLjGqUEXonsQeA_jcE=69Gg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-Posted-By: 94.0.205.114
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: markyr@gmail.com (Mark Randall)
Message-ID: <php.internals-105384@news.php.net>

On 24/04/2019 15:35, Chase Peeler wrote:
>> Total files scanned:  20,767
> Total lines scanned:  4,013,170
> Total short open tag references:  6,787
> Total files w/ short open tag references:  1,665

1. Open project in PHPStorm (or equivalent).

2. Run inspections.

3. Click convert short open tags.

Personally I prefer the shorter look of "<? if(...) { ?>" when writing 
templates, but not enough to be up in arms about its removal.

If anything I'm more concerned about potential code + data leaks.

Something which was previously perfectly legitimate code, no longer 
being considered code, could be quite the problematic situation... 
especially if that code happened to be protective logic such as "if" 
statements.

<? if ($admin) { ?>
   User secret: <?= htmlspecialchars($secret) ?>
<? } ?>

I would have preferred that the parser encountering <? threw a compile 
error for quite some time rather than just magically ceasing to be 
relevant.

The XML argument holds no weight with me.

--
Mark Randall