Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105528
MIME-Version: 1.0
References: <CAFPFaMJEn=gjk5jAAxR2bF=4Mt3r0FJCm6mbOCReOmyybtAkkg@mail.gmail.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> <000401d4fac8$ae592cf0$0b0b86d0$@roze.lv>
 <CAJHtznz-Dm7ft6qJ6Y6sjnaL4G0cwVVJyakxr_zprhxQzqUkVg@mail.gmail.com>
 <CAFPFaML4QTbtJXLuheGwTTT204vY40TeT5TLEX22oYTNrNJ8Qg@mail.gmail.com>
 <CAJHtznwnbM54uAzStVfAOjUTgEoDr8XpOFCYdVjgrtZfFgrSJw@mail.gmail.com>
 <CAFPFaM+EGh6zZgSdDXo06wdY==Fujm1JFWFO88EmvggC-fdFJA@mail.gmail.com>
 <CAJHtznztD-UOSoeSApvTMidNo6z20MUWNNBRUW84_JxM0fRq-g@mail.gmail.com>
 <alpine.DEB.2.21.1904301800070.9606@singlemalt.home.derickrethans.nl> <CAJHtznzSOo1Xbmu3N9C_GEo6woDC0STVR_nVjUCusT65dfPe=A@mail.gmail.com>
In-Reply-To: <CAJHtznzSOo1Xbmu3N9C_GEo6woDC0STVR_nVjUCusT65dfPe=A@mail.gmail.com>
Date: Tue, 30 Apr 2019 22:18:55 +0200
Message-ID: <CAAfnsFWogfyZ=X07EOAZ6V4vSKw89K01WGnddRF=zRP9-FBsdg@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Derick Rethans <derick@php.net>, "G. P. B." <george.banyard@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: peterkokot@gmail.com (Peter Kokot)

Hello,

On Tue, 30 Apr 2019 at 20:25, Zeev Suraski <zeev@php.net> wrote:
>
> On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans <derick@php.net> wrote:
>
> > On Mon, 29 Apr 2019, Zeev Suraski wrote:
> >
> > > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. <george.banyard@gmail.com>
> > wrote:
> > >
> > > > I think this just boils down to what is an acceptable majority, if
> > > > 2/3 is not enough then 3/4 but this is another debate altogether.
> > > >
> > >
> > > I've argued in the past that it would make sense to require a 9/10
> > majority
> > > for RFCs.  Very few RFCs that passed - only cleared a 2/3 majority.
> > > Usually (in the vast majority of cases), it either clears a nearly
> > > unanimous vote - or it doesn't even come close to 2/3.
> > >
> > > RFCs that have a high number of votes (i.e., that people feel strongl=
y
> > > about), and barely pass the 2/3 mark - are controversial and saw
> > division.
> > > Yes, it means that out of the (almost random) group of people who are
> > > currently enabled to vote by our (flawed) voting system
> >
> > If you think it's flawed
>
>
> It's not that I think it's flawed - I know it's flawed.  It doesn't
> implement what was agreed upon when the Voting RFC was enacted.
>
>
> > , you know that the RFC process is there for
> > anybody to change it. Joe already managed twice towards what you
> > suggested in your stalled RFC:
> >
> > - https://wiki.php.net/rfc/abolish-short-votes
> > - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
> >   against this one to raise the barrier from 50%+1 to =E2=85=94rds).
> >
>
> I'm well aware of it.  In doing that, I think we greatly complicated the
> prospects of fixing the voting eligibility - which is an infinitely hotte=
r
> potato to handle. Both 'abolish' RFCs enjoyed popular support and had ver=
y
> little touchy subjects - unlike the topic of who gets to vote, or the
> prospect of moving to a consensus-based system.
>
> > It's absolutely fine to dislike short tags.  It's absolutely fine to
> > > believe it shouldn't have been introduced.  But the gap between that,
> > > and thinking it's fine to remove it - is very, very big.
> >
> > But the fact is that the RFC passed. And retroactively changing rules
> > because somebody don't agree with a decision is making a farce out of
> > the process.
> >
>
> I've detailed the issues with the RFC in my other reply.
>
> I'm well aware that I'm spending quite a bit of 'credit capital' by
> weighing in on this, and I'm enjoying it roughly as one would enjoy havin=
g
> their tooth pulled out without anesthesia (which still pales in compariso=
n
> to what it would take to fix our voting process, which will probably be
> akin to having an entire set of teeth pull out in the same way).   The
> reason I'm still doing it is that it's clear this RFC was flawed in its
> voting options, its substance, and the level of discussion that surrounde=
d
> it (the last one is my opinion, the first two are facts) - and it will ha=
ve
> HUGE implications on hundreds of thousands if not millions of users.  So =
as
> I said when I first engaged this thread - as much as I'm 'enjoying' this,=
 I
> prefer to take the personal hit and do whatever I can to prevent our user=
s
> from taking the hit.
>
> If we are to inflict this hit on our users - we need to have each and eve=
ry
> t crossed and i dotted.
>
> Zeev

Some languages out there have an idiom for this kind of a situation:
This thread right here is making an elephant out of the fly. Meaning
something is exaggerating or make something more serious than it
actually is.

Worth noting another inconsistency here that we've missed. PHP 7.4 has
introduced many BC breaks actually already. Without this level of
problems:
- *nix build system now uses pkg-config and basically has changed so
many configure options that building this is a completely new chapter
on its own
- removed wddx
- removed interbase
- entire Backward Incompatible Changes section in the UPGRADING file:
https://github.com/php/php-src/blob/PHP-7.4/UPGRADING

The deprecation in PHP 7.4 (or even if there wouldn't be any
deprecation here at all) and removal of some short tags in PHP 8 is
the least of users problems I think.

If the next RFC on this topic would happen (in my opinion it is
pointless) it should make only something more clear. That is how to
remove them. In PHP 8.0 directly as is now the result of this RFC or
in PHP 9.0 removal and in PHP 8.0 using a compilation error. Anything
in between is a more or less a revert of the original RFC which would
then come to a question of why making these RFCs at all and why voting
even matters.

Without these kind of "hacks" PHP wouldn't even move forward anymore.
Contributing to it would be in most cases only maintenance, fixing
bugs and compatibility with platforms out there. So nothing exciting
anymore like making it more syntactically correct, more logical etc.
(these are very important changes also beside new functionality and
extensions).

--=20
Peter Kokot