Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105529
MIME-Version: 1.0
References: <CAFPFaMJEn=gjk5jAAxR2bF=4Mt3r0FJCm6mbOCReOmyybtAkkg@mail.gmail.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>
 <5741936F-B1F4-43C7-B815-F9D8030AC7BB@koalephant.com> <e5c10f59-bde9-dadc-e837-266f870b6358@lsces.co.uk>
 <B392E7C8-BBAC-48D2-BBBA-3D7C7EFD9595@koalephant.com> <e702a5cc-9567-0591-8f5e-b14aef0766b7@lsces.co.uk>
 <CAAfnsFU1B61qaPRAh5uNTWMALcV5xmae0Yb1yY9+QaAGLVGx7A@mail.gmail.com>
 <49A4B76C-4C62-4CBE-BA20-FBE56CA29AB0@cschneid.com> <CADyq6sL7m=A=pA1rNBg_CFOoMtfCZn50AfALh9jtLHvn9NRzmw@mail.gmail.com>
 <609E93CF-099B-446C-AD28-04F1D802C9F0@cschneid.com> <CADyq6s+6Gqaa6Werc0Vn=gKWrrqC71+ry1rpsPEpq4BSE4wq_Q@mail.gmail.com>
 <CAPKYkKz4u-D3ebVJCU8TgCuEGVVC28-YSj76sCU1TS4BaDjeBA@mail.gmail.com>
 <CAAfnsFUAY_O9JbDWMsntFKz1otTjE0BKYrsMif3DzG+zQpahxw@mail.gmail.com> <85e05f77-e828-9634-adec-f7d798d9f0b8@phpgangsta.de>
In-Reply-To: <85e05f77-e828-9634-adec-f7d798d9f0b8@phpgangsta.de>
Reply-To: bishop@php.net
Date: Tue, 30 Apr 2019 16:23:44 -0400
Message-ID: <CAEYWF=5qzDCgDkwJ_e7pceuLkinptNAxueeVo0N=WA2K8haO-g@mail.gmail.com>
To: Michael Kliewe <info@phpgangsta.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000134acf0587c52fb7"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: bishop@php.net (Bishop Bettini)

--000000000000134acf0587c52fb7
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 24, 2019 at 8:19 PM Michael Kliewe <info@phpgangsta.de> wrote:

> Some random thoughts:
> - What happens to .phar files? Do we have to scan the contents?
>

Phar relies upon the engine's tokenizer. If your phar build script uses <?,
then you need an engine that supports <? to build your phar. If your phar
contains files that each use <?, you need an engine that supports <? to run
your phar.

    $ cat create-test.phar.php
    <?php
    $phar = new Phar('test.phar');
    $phar['index.php'] = '<? echo "I am a short tag" . PHP_EOL;';
    $stub = $phar->createDefaultStub('index.php');
    $phar->setStub($stub);

    $ php -d phar.readonly=Off create-test.phar.php

    $ php -d short_open_tag=On test.phar
    I am a short tag

    $ php -d short_open_tag=Off test.phar
    <? echo "I am a short tag" . PHP_EOL;

This is the same problem library maintainers face: one can't distribute a
phar using <? anywhere and expect it to run everywhere. Since phar files
are far more portable than say a zip file of code - like being directly
runnable from the command line - engine compatibility is a primary concern
for phar distributors. Of course, if one wrote phar for controlled
distribution, then one might not have considered this angle. These are the
folks we need to worry about in this deprecation.

So, yes, any extant .phar files using <? need to be re-built with contents
using <?php. Note that means phar contents created by string need to be
manually checked for <? as well. Said another way, php-cs-fixer would not
fix my phar example from above, because <? is embedded in a string. The
grep+sed solution might work for that [1].

In my opinion, both as maintainer of the phar extension and a long-time
user of PHP, we need engine-enforced deprecation sooner rather than later.
We should also move toward outright removal at a prudent speed. But I would
caution that if long, long-time community members and lodestars are saying
"outright removal in 8.0 is too soon" then we should heed that. Once we
remove it, it's gone and there's no going back.

[1] A phar file scanner looking for instances of <? inside a phar could
also be written. I'd be willing to lead that development if there's
interest.

--000000000000134acf0587c52fb7--