Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77126
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <3619E7A6-6D76-498D-9082-855DAE937C1E@ajf.me>
Date: Wed, 10 Sep 2014 02:32:41 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F005B7B2-9407-4387-826C-E0FFAFE7C8B7@ajf.me>
References: <CAF+90c_V0S6KhCLvkRZEcaQQ-Qv_oNaV9EJ_faOo9ZnVRLXQ0g@mail.gmail.com> <3619E7A6-6D76-498D-9082-855DAE937C1E@ajf.me>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] Remove alternative PHP tags
From: ajf@ajf.me (Andrea Faulds)


On 10 Sep 2014, at 01:21, Andrea Faulds <ajf@ajf.me> wrote:

> Isn=92t this a bit of a needless BC break? Not very nice on people =
with such codebases. It=92s also worth pointing out that people might be =
using these to get around the XML <? issue (granted, you can disable =
short tags).
>=20
> I=92d vote for this if you wrote a convertor script to help people =
migrate. Otherwise I think we=92re just being unfair on people who used =
these tags.
>=20
> Actually, I=92d like to see a Python 2to3-esque tool in general for =
PHP 7. The easier we make the migration, the more likely people will do =
it.

Some further thoughts after discussing with Tyrael (Ferenc) on IRC.

I initially thought that I=92m not really against removing them really, =
but I think we should have a script to convert them first. Because =
someone, somewhere, is gonna need it.

But then I=92ve thought more about it. I=92m usually OK with certain BC =
breaks, I just don=92t like this specific one. It doesn=92t affect me, =
but, well, I don=92t see the point. It doesn=92t really help language =
consistency or anything, (OK, sure, only two sets of delimeters now, but =
it=92s not a big deal like some other things are), and you=92ll force =
people to update every file in their codebase if they=92re affected, =
assuming people who use alternative tags use them everywhere. There=92s =
also a security issue here. If someone uses PHP 7 with a codebase that =
has these alternative tags, your code is now visible to users instead of =
the output, which might include configuration details like database =
passwords or password hash salts. It=92s also possible that people won=92t=
 notice this is happening if they only used these alternative tags in a =
few obscure places.

I wonder if, really, we might be better off keeping them around and just =
outputting E_DEPRECATED. If we do get rid of them in 7, we should have =
5.7 deprecate them.
--
Andrea Faulds
http://ajf.me/