Re: [RFC] [VOTE] Deprecate PHP's short open tags
| From: | Nikita Popov | Date: | Mon, 29 Apr 2019 08:17:12 +0000 |
| Subject: | Re: [RFC] [VOTE] Deprecate PHP's short open tags | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-105503@lists.php.net to get a copy of this message | ||
On Sun, Apr 28, 2019 at 10:02 AM Zeev Suraski <zeev@php.net> wrote:
> On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis <r@roze.lv> wrote:
>
> > Also imo the reason why people write now (and not in the discussion
> > phase) because for some time in the voting there wasn't the 2/3 majority
> > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2
> > votes make the difference.
> >
> >
> At least for me, this definitely was the case. When I voted, it was
> nowhere near clearing the 2/3 threshold.
>
> 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.
>
Keep in mind that for example the FFI RFC passed with something like 60%
majority, even lower than this RFC. I think you're cherry-picking a bit
here, when it comes to what should and shouldn't pass ;)
Process wise we're in a bit of an unchartered territory here, but I don't
> think we should let the headache involved with figuring out how to reverse
> this decision force us to impose this on our users. It's better to go
> through this unpleasantry now than deal with the backlash later.
>
I think that process-wise (if we can't agree on landing some variation of
this, as I've suggested in a separate thread) the right thing to do would
be to draft a new RFC that overrules this one. It can lay out the new
arguments that have come up in the meantime in an orderly manner and be
voted separately.
Nikita