On Mon, Jun 17, 2019 at 1:55 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Fri, May 24, 2019 at 6:53 PM Peter Kokot <peterko...@gmail.com> wrote: > > > Hello, > > > > On Sat, 11 May 2019 at 20:56, Peter Kokot <peterko...@gmail.com> wrote: > > > > > > Not trying to rush anyone to something they have no energy working on > > > anymore here but what's the plan here then? And what plan is there > > > with these short tags on the long run? > > > > I'm just checking then why is this RFC in the pending implementation > > state if basically we're on a way to have the short opening tags in > > PHP for ever... Maybe we should then enable them by default to have > > the other way around situation of having both tags for few 10 years > > and then ditch the long one if it's not going to be deprecated in PHP > > 7.4 and decided what to do with them? > > > > https://wiki.php.net/rfc/deprecate_php_short_tags > > > > Girgias has put up a new implementation at > https://github.com/php/php-src/pull/4263. > > If short_open_tag=On and <? is used, a single deprecation warning is > thrown. short_open_tag=On remains the default, so there will be no > accidental code leakage due to changed defaults. If short_open_tag=Off, > then <? in the code are ignored as usual. > > I believe that addresses the implementation concerns and we can go ahead > with landing this RFC. > Nikita, I wrote a fairly detailed response to why I believe we should re-do the RFC and vote, given multiple issues with the original one. While there was a response to it, I very much stand by what I said in it - namely, that the discussion was toe-deep in a way that is unbecoming for such a basic building block (as unpopular as it may be), that some of the motivations mentioned in the RFC were simply wrong (e.g. 'simplification of the parser') and that the voting options were confusing - which may have impacted the vote in certain ways. I see no way forward other than redoing it. This feature has been with us for over 20 years, we can spend a couple of more weeks deprecating it properly if we really need to (and perhaps consider the 'legacy' extension option - providing a win-win of sorts, where we can both move forward with 'cleanups' - but also provide a painless path forward for the ones affected). Zeev
