Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105487
MIME-Version: 1.0
References: <CAFPFaMJEn=gjk5jAAxR2bF=4Mt3r0FJCm6mbOCReOmyybtAkkg@mail.gmail.com>
 <CAOv67gsiva80KEhw7D2N2qKCz0gZvza30EDL7SZoJRPFsGoROA@mail.gmail.com>
 <0ec42fa9-77d1-a203-8425-e72fdd5071f3@korulczyk.pl> <06473788-a34b-f041-36e6-31d19d8dda4c@cubiclesoft.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>
 <000401d4fac8$ae592cf0$0b0b86d0$@roze.lv> <CAJHtznz-Dm7ft6qJ6Y6sjnaL4G0cwVVJyakxr_zprhxQzqUkVg@mail.gmail.com>
 <CAFPFaML4QTbtJXLuheGwTTT204vY40TeT5TLEX22oYTNrNJ8Qg@mail.gmail.com> <CAJHtznwnbM54uAzStVfAOjUTgEoDr8XpOFCYdVjgrtZfFgrSJw@mail.gmail.com>
In-Reply-To: <CAJHtznwnbM54uAzStVfAOjUTgEoDr8XpOFCYdVjgrtZfFgrSJw@mail.gmail.com>
Date: Sun, 28 Apr 2019 22:30:58 +0200
Message-ID: <CAFPFaM+EGh6zZgSdDXo06wdY==Fujm1JFWFO88EmvggC-fdFJA@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Reinis Rozitis <r@roze.lv>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000494ba305879d0f3d"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: george.banyard@gmail.com ("G. P. B.")

--000000000000494ba305879d0f3d
Content-Type: text/plain; charset="UTF-8"

On Sun, 28 Apr 2019 at 14:36, Zeev Suraski <zeev@php.net> wrote:

> As I said numerous times in the past, I'm a firm believer that
>>> controversial RFCs (ones that generate a lot of votes with a substantial
>>> number of opposers) should not pass.  I think this is important when
>>> adding
>>> features - but it's actually a lot more important with deprecations.
>>> When
>>> there's substantial doubt whether a deprecation should go through or not,
>>> there should be no doubt at all - it shouldn't.  This is one of the
>>> clearest cases if not the clearest one we've had to date.
>>>
>>
>> This IMHO applies to the deprecation vote which includes the default
>> change
>>
>
> From my POV it applies to all deprecations, although obviously taking out
> something that's been a basic building block for the last 20+ years is
> probably more of an issue than some 3rd party utility function.
>

 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.

(and seems that is where people disagree as more people vote for the removal
>> without the deprecation notices which seems to point this is the issue)
>> which in hindsight is a stupid thing to do, but I would have loved that
>> people
>> point out to this specific issue (and the voting structure) during the
>> discussion
>> or even at the beginning of the vote.
>>
>> But basing my self on the vote to remove the short open tags in PHP 8,
>> which
>> cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes
>> without any
>> "YES" votes to be on the 2/3 threshold. Whereas the deprecation votes
>> "only"
>> needs two (2) votes to be on the 2/3 threshold.
>>
>
> That's not how I understood the vote - although honestly, I found the vote
> layout to be a bit weird.
>
> There are are two issues here:
> 1.  Secondary votes only kick in if the primary vote passes.  They're also
> defined as votes where you only need a simple majority for one of the
> options.
> 2.  The two questions are, in fact, one and the same.  Removing a feature
> in a major version requires that we first deprecate it in a mini version,
> in other words - we can't remove something in 8.0 in case it's not first
> deprecated in 7.4.
>
> I admit I found this confusing that the two votes were separate, but the
> way I understood it, is that we may actually deprecate it at 7.4, without
> actually removing it at 8.0, but just keeping it deprecated.  The other way
> around (removing it in 8.0 without first deprecating it in 7.x) is against
> our rules.
>

This was indeed the intention of the voting structure as I wanted to have a
vote to get see
if people were filling to remove it with PHP 8 or leave it longer in the
Engine.

However looking at how some people voted against the deprecation notice but
for the removal
the only meaningfull conclusion I can come up with is that the change of
the default value is
the issue.


> I mean I don't see how we are in unchartered territory, the vote passed,
>> sure
>> with not a huge supra majority but it still passed.
>>
>
> We're in unchartered territory not from a process perspective, but in
> terms of the number of core devs who think it's a really bad idea and the
> fact we're rediculously close to the minimum threshold - for something that
> should really happen with consensus.
>

I can see this but is it really unheard of?


> Moreover going about how Twitter [2] reacted (which isn't necessarely a
>> good
>> metric) it seems a *vast* majority is in favor of this change.
>>
>
> It is, indeed, not a very good or even meaningful metric at all.  The
> folks which are likely to care about this are almost definitely severely
> under-represented both here and on the dev cycles on Twitter.
>

This may well be true but by the same argument I can say that a lot of
people are for this
even tho they didn't express this as much as those against it.


> I can consider it but I am really not keen on it.
>>
>
> I'd sincrerely appreciate it if you did.  I'm not fond of fighting
> windmills, even less so nowadays than in the past - but I really think
> we're making a painful mistake for virtually no gain, and I'm pretty sure
> I'm not alone in thinking that.  Ultimately, nothing in the RFC is new
> compared to what we knew back in 1998 when we decided to have short open
> tags.  There are no new developments that make it more relevant today than
> it was back then - if anything, XML is a lot less important today than it
> was back then (when it was all the rage).  And unlike 1998, the cost
> assocaited with deprecating it now is tremendous.  So even if we can argue
> whether we took the right decision 20 years ago - there's really no new
> grounds to reopen that decision today.
>

The problem is if we don't address it now it will be even more complicated
when
PHP 9 rolls around and then again. I still believe these short tags are a
legacy
oddity that should be removed.

Because what prevent me from then re-openning the vote again if the vote
>> then fails?
>>
>
> Nothing really, other than common courtesy.
> I was even hoping that the RFC will be withdrawn given the number of nays
> from core devs, but that's of course something that is up to you.
>

In all honesty I didn't check who votes for what as IMHO everybody is
entitled
to their opinion.


> What happens if the deprecation vote fails but not the removal?
>>
> Would this imply changing how it is deprecated which is literally the
>> topic of the
>> other thread without any more voting which I'm totally open to how it is
>> changed?
>>
>> I don't even mind still having a compile error in PHP 8 when it sees the
>> token
>> as I said before I don't really care that much about the timeline.
>>
>
> I think the real question this RFC raises is whether we want to deprecate
> <?
> There are several valid options:
> - Do nothing (which probably gets my vote)
> - Deprecate it in 7.4, and remove it in 8.0
> - Deprecate it in 7.4, and error out over it in 8.0
> - Deprecate it in 8.0, and figure out what we want to do with it as we
> gear towards 9.0 (which would give us time to gauge the feedback before
> taking decisions - something that won't really be possible with 7.4/8.0
> given the short timelines)
>
> What I don't really think is a possibility is removing it (one way or
> another) in 8.0 without first deprecating it in 7.4 (which again, is what I
> found a bit confusing about the vote options).
>
> I would consider restructuring the questions in a different way than they
> currently are and restart the vote:
>
> Primary Question - Deprecate short open tags yes/no  (requires 2/3
> majority)
> Secondary Question - which version 7.4/8.0  (simple majority)
> Secondary Question - what to do when we remove it - silent removal, error,
> something else?  (simple majority)
>
> Thanks,
>
> Zeev
>

The problem I have with putting this again to a vote is that it feels
revote until the
outcomes is convenient to me. And going with this logic I feel I could say
let's
redo a vote to deprecate the var keywword as the last vote was 3 years ago
and maybe opinions have changed. It just end in more resentment IMHO.


On Sun, 28 Apr 2019 at 21:46, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> On 4/28/19 4:52 AM, Benjamin Morel wrote:
> >> I don't even mind still having a compile error in PHP 8 when it sees the
> > token
>
> I thought one of the arguments for the whole enterprise was to enable
> <?xml to pass through PHP? Isn't that what the RFC was claiming? So this
> obviously won't work with this solution. And the "parser simplification"
> claimed by RFC would also not happen, I imagine, since there's still two
> separate tokens. So we are already out of at least half the reasons
> original RFC has claimed...
> --
> Stas Malyshev
> smalyshev@gmail.com


Oh good to have you onboard for the initial RFC and remove it with PHP 8.
I suppose the discussion is closed then in this case. :)

Best regards

George P. Banyard

--000000000000494ba305879d0f3d--