Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104926
Return-Path: <r@roze.lv>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 14673 invoked from network); 25 Mar 2019 16:59:38 -0000
Received: from unknown (HELO zeona.lv) (213.175.74.1)
  by pb1.pair.com with SMTP; 25 Mar 2019 16:59:38 -0000
Received: from MezhRoze (unknown [10.8.0.69])
	by zeona.lv (Postfix) with ESMTP id D82852006EC71
	for <internals@lists.php.net>; Mon, 25 Mar 2019 15:52:46 +0200 (EET)
To: "'PHP internals'" <internals@lists.php.net>
References: <CAFPFaML1KT2WMhUkZg4rZz3BDV68oPCCufx5+0c26Js--gXj_Q@mail.gmail.com>
In-Reply-To: <CAFPFaML1KT2WMhUkZg4rZz3BDV68oPCCufx5+0c26Js--gXj_Q@mail.gmail.com>
Date: Mon, 25 Mar 2019 15:52:45 +0200
Message-ID: <000301d4e312$06a88190$13f984b0$@roze.lv>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQGcIFfGlc3WAXT7RHi3cV0eE5t8o6aN3aXQ
Content-Language: lv
Subject: RE: [PHP-DEV] [RFC] Deprecate PHP's short open tags
From: r@roze.lv ("Reinis Rozitis")

> I would like to start the discussion about the deprecation of PHP's =
short open
> tags:
> https://wiki.php.net/rfc/deprecate_php_short_tags

Hi,=20
I did read the initial thread about this and now the RFC and it doesn't =
really state what is the reason of removing the short tags besides this =
one line:
"PHP has provided over the years different ways to indicate the =
beginning of PHP code other than the standard <?php ... ?>"

Is there a (noticeable) speed improvement or does it make the =
parser/engine more simple? Is it wrong to provide different ways to =
indicate the start of php code?
Since the short '<?' came first one could argue which is the 'standard'.

Also considering there is somewhat low adoption of new php versions [1] =
a change which brakes a lot of legacy code might even further push back =
the switch to modern/current versions (at least now even if the defaults =
disable the short tags, there is an option to reenable the =
functionality).
Obviously you could say that those using old versions won't be affected =
anyways and those using php 7.x and waiting for 8.x will use recent =
application code and also won't notice this deprecation, but in my =
opinion (and praxes) it isn't always the case.

[1] https://w3techs.com/technologies/details/pl-php/all/all

rr