Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106667
MIME-Version: 1.0
References: <CAFPFaML19B_RehrUQLEy_oFae-H5r3+BpUGg=GF1js83cJpJqQ@mail.gmail.com>
 <CAEYWF=4cx_i=3rCfFKeBT0Jq0e4=P0PeY2wd6YEwog_VdA1+Dg@mail.gmail.com>
 <CAJHtznzie34C92y2nTRXxhD99FEW-5hmruVatsrLDHcAKvTccQ@mail.gmail.com>
 <CAEYWF=7S2SxzxU+TzRV0Rc7FNMvyZBkAENVTNbZKqrs71Uyijw@mail.gmail.com>
 <000001d54e5a$02ac09f0$08041dd0$@roze.lv> <2b5588d6-d667-321f-22f1-46a22bb797c5@korulczyk.pl>
 <000001d54ea3$eb3480a0$c19d81e0$@roze.lv> <ad6b9615-372d-69ba-9ca5-e8fa554c5aea@korulczyk.pl>
 <000301d54ead$b43e7b00$1cbb7100$@roze.lv> <59378662-77ca-0779-10cb-c25acf1b45ef@korulczyk.pl>
 <CAKOpQSySEqE4VR+b0Twp4NxZMa+ruEYTbV7qr38Tcw8wqobH2A@mail.gmail.com>
 <CAFPFaMKBWEo-MXCP75vFt2JEvNXzLVhW=f2gGaGHSazb1oXK8Q@mail.gmail.com>
 <CAAfnsFUQ1mKGdqkekCxU7+C6Rr48WBAajoD-ut4bk8UD=GU4Zw@mail.gmail.com> <CAPKYkKzpEN8Q-2_CfnJkTNJTmDCDLX2h7UfRfetP+2JJaeuOWA@mail.gmail.com>
In-Reply-To: <CAPKYkKzpEN8Q-2_CfnJkTNJTmDCDLX2h7UfRfetP+2JJaeuOWA@mail.gmail.com>
Date: Tue, 20 Aug 2019 18:18:08 +0200
Message-ID: <CAAfnsFUv13iAMVZ-MqNP25NBmvADMKon7KWhTCBpPY-BG2VwFQ@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: "G. P. B." <george.banyard@gmail.com>, PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
From: peterkokot@gmail.com (Peter Kokot)

On Tue, 20 Aug 2019 at 18:02, Chase Peeler <chasepeeler@gmail.com> wrote:
>
> On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot <peterkokot@gmail.com> wrote:
>
> > On Tue, 20 Aug 2019 at 14:51, G. P. B. <george.banyard@gmail.com> wrote:
> > >
> > > Hello internals,
> > >
> > > This RFC has been declined with 56% in favour (30/54) and 44% against
> > > (24/54).
> > >
> > > Two side notes to this:
> > >
> > >   - I seriously don't appreciate that the RFC has been edited *WITHOUT*
> > my
> > > knowledge to add endorsement names on the counterargument to the RFC on
> > the
> > > RFC itself  when the appropriate place would have been the counter
> > argument
> > > document.
> > >   - As it has no clear supra majority (nor against nor in favour), this
> > > topic should probably be put to discussion again in some way or form at a
> > > later stage.
> > >
> > > Best regards
> > >
> > > George P. Banyard
> >
> > The number of things that got wrong in these two RFCs is
> > extraordinary.
>
> What was done incorrectly in regards to the second RFC?
>
>
> > If anything the community, the internals and everyone
> > involved got through a good thinking process so we have learned
> > something from this in any way. I appreciate all your time and effort
> > to move this thing forward and even for being so respectful towards
> > Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the
> > PHP and to repeat the voting with a better solution in this RFC.
> >
> > You say that like being respectful to people with opinion different than
> yours is something worth commending, when it should be the default
> behavior. In other words, you are implying that anyone that opposed this
> RFC didn't deserve respect, so, congratulations to everyone for showing it
> anyway.
>
>
> > I think that now we need to fix the documentations out there. short
> > tags will stay in PHP for at least another 10+ years, so maybe we
> > should simply consider them not a part of legacy but a special kind of
> > a feature. There are some parts in PHP comments and docs that needs
> > this fixed and sorted out better a bit (probably - specially in the
> > ini files itself etc).
> >
> > I think we should still discourage their use. We should be explicit in the
> documentation that code which uses short tags might not be portable. Just
> because they exist, doesn't mean we should suddenly change our treatment of
> them when it comes to best practices. If there is any documentation that
> doesn't make this clear, submit a bug report.
>
> If you really feel that we should start treating short tags as totally
> legitimate, then someone else with better knowledge of how to proceed with
> that will need to provide advice.
>

Let's simplify this a bit because I'm not sure I have seen anyone
mentioning something like a PHP 10 milestone in all these discussions.
If we want to get rid of some feature like this a very long timeline
needs to be done and also major versions needs to be taken into
consideration. And from all the discussions I got a feeling that not
everyone who voted "No" (who want the short tags in PHP) also want to
get rid of them. Ever. So that's why. We can live with short tags in
PHP as a feature. And so can legacy projects be upgraded to not use
them anymore so nothing to worry too much I think anymore now. We'll
discuss this maybe in 5 or 10 years then. About the docs - there are
very minor changes needed where "backwards compatibility" is mentioned
maybe. Because they are not in PHP for keeping BC anymore now. Nobody
proposed a better solution than this RFC, then they are a feature.
Cheers.

-- 
Peter Kokot