Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106278
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Content-Type;
	b=VkEEXGqMPpgsNnC1N0JKmcUHbzQ7z5asTTpU8R7EiPxx6W5uZ4J7trvSoSc51I
	bWt4YRjrWQrB7E7NVggbG7vAqlIjg7xPqFVWo+HWflwM9yOoidf/tQUXOI8XCFy7
	ebzKGpjwB4onpagGVs5BfkT+Tn8DxGiCrULS32BVQHgcE=;
MIME-Version: 1.0
References: <CAFPFaMLpZ=okschrpeH77AhZTHcvFBuPf1S1bXH6psxmvABK7g@mail.gmail.com>
In-Reply-To: <CAFPFaMLpZ=okschrpeH77AhZTHcvFBuPf1S1bXH6psxmvABK7g@mail.gmail.com>
Date: Wed, 24 Jul 2019 06:54:55 +0300
Message-ID: <CAJHtznxb-KUgUgDMoB3srpL6ajAQv2Uo3qHttv34svCuDzUGHg@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005b23e9058e6546e0"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
From: zeev@php.net (Zeev Suraski)

--0000000000005b23e9058e6546e0
Content-Type: text/plain; charset="UTF-8"

[Had an issue with my email client, apologies if it ends up being sent
twice]

On Tue, Jul 23, 2019 at 8:55 PM G. P. B. <george.banyard@gmail.com> wrote:

> Hello internals,
>
> Due to the controversy after the initial vote on the Deprecate PHP's Short
> Open Tag RFC [1] here is a new RFC to deprecate them written with the help
> of Nikita Popov <nikic@php.net>.
>

George,



Thanks for creating a new RFC instead of going into a bit of a procedural
limbo.  I appreciate that.




Everyone,



Much of the feedback for v2 was around the problematic idea of changing
behavior between 8.0 and 8.1, but little was said on the premise of the
proposal itself.  Much like the original RFC, the rationale for this
deprecation remains quite weak.  The differences are that it's clearer now
(3 separate motivations were rightfully condensed into just 1), and the
bogus motivation that this would somehow simplify the parser was removed.
But same as with the original RFC - this RFC creates the impression of a
problem that doesn't really exist, and then provides a way of fixing it -
while the 'do nothing' option remains a vastly superior outcome in terms of
gain vs. harm.



The simple reality is this:

- Absolutely nothing changed about <? since its introduction in 1998, for
better or for worse.  The reasoning - about portable code/ini settings, as
well as XML - was there 21 years ago when it was introduced - and still, it
was introduced.

- If anything, XML became a lot less relevant.  There were *intense*
discussions about <? back in 1998, since back then - <? was all the rage.
It was perceived as one of the most basic and fundamental building blocks
of the future Web to be - as SOAP was beginning to form up and everyone
thought this was the future of Web-based services, as well as virtually
anything else - from config files to databases.  Reality, as we all know,
took slightly different turns - and XML is a lot less relevant today than
it was 21 years ago.  It looks categorically anachronistic to care more
about it today than we did back then.

- Short tags were *never intended for portable code*, and users who use it
know that very well.  From the get go, <?php was introduced as the portable
start tag - and let's be honest with ourselves - everyone who remotely
cares about portability (as well as many if not most of those who don't) -
use it exclusively.  Virtually all frameworks and projects have coding
standards that disallow short tags.  You need to purposely turn it on in
your own deployment - people and companies who use it use it exclusively
for internal purposes.



Which, in turn, translates to this:

- The motivation for removing short tags today is a lot weaker than the
motivation was not to add it in the first place back in 1998 (XML being a
lot less important).  This makes for an unreasonable basis for deprecation.

- Perhaps it was a mistake adding it in the first place, perhaps not.
Either way - the motivation for proactively removing it - and hurting users
in the process - is simply not nearly sufficient when weighting the
gain/harm balance:  Everyone who's not using it (presumably, mostly
everyone reading this message) will be unaffected.  Everyone who is using
it will be remarkably unimpressed with the weak reasoning for removing it,
and rightfully so.



This is a clear net-loss RFC if I've ever seen one.  I'm saying that as
someone who (like most of you) never uses short tags, but at the same time
is not missionary against those who are and have been peacefully using them
for potentially decades.



I do think that these counterpoints should be represented in the RFC, as
many folks vote on RFCs without regularly reading all messages on internals@.
I'll be happy to add them (of course, in a condensed summarized fashion).



Thanks,



Zeev

--0000000000005b23e9058e6546e0--