[Had an issue with my email client, apologies if it ends up being sent twice]
On Tue, Jul 23, 2019 at 8:55 PM G. P. B. <george.bany...@gmail.com> wrote: > Hello internals, > > Due to the controversy after the initial vote on the Deprecate PHP's Short > Open Tag RFC [1] here is a new RFC to deprecate them written with the help > of Nikita Popov <ni...@php.net>. > George, Thanks for creating a new RFC instead of going into a bit of a procedural limbo. I appreciate that. Everyone, Much of the feedback for v2 was around the problematic idea of changing behavior between 8.0 and 8.1, but little was said on the premise of the proposal itself. Much like the original RFC, the rationale for this deprecation remains quite weak. The differences are that it's clearer now (3 separate motivations were rightfully condensed into just 1), and the bogus motivation that this would somehow simplify the parser was removed. But same as with the original RFC - this RFC creates the impression of a problem that doesn't really exist, and then provides a way of fixing it - while the 'do nothing' option remains a vastly superior outcome in terms of gain vs. harm. The simple reality is this: - Absolutely nothing changed about <? since its introduction in 1998, for better or for worse. The reasoning - about portable code/ini settings, as well as XML - was there 21 years ago when it was introduced - and still, it was introduced. - If anything, XML became a lot less relevant. There were *intense* discussions about <? back in 1998, since back then - <? was all the rage. It was perceived as one of the most basic and fundamental building blocks of the future Web to be - as SOAP was beginning to form up and everyone thought this was the future of Web-based services, as well as virtually anything else - from config files to databases. Reality, as we all know, took slightly different turns - and XML is a lot less relevant today than it was 21 years ago. It looks categorically anachronistic to care more about it today than we did back then. - Short tags were *never intended for portable code*, and users who use it know that very well. From the get go, <?php was introduced as the portable start tag - and let's be honest with ourselves - everyone who remotely cares about portability (as well as many if not most of those who don't) - use it exclusively. Virtually all frameworks and projects have coding standards that disallow short tags. You need to purposely turn it on in your own deployment - people and companies who use it use it exclusively for internal purposes. Which, in turn, translates to this: - The motivation for removing short tags today is a lot weaker than the motivation was not to add it in the first place back in 1998 (XML being a lot less important). This makes for an unreasonable basis for deprecation. - Perhaps it was a mistake adding it in the first place, perhaps not. Either way - the motivation for proactively removing it - and hurting users in the process - is simply not nearly sufficient when weighting the gain/harm balance: Everyone who's not using it (presumably, mostly everyone reading this message) will be unaffected. Everyone who is using it will be remarkably unimpressed with the weak reasoning for removing it, and rightfully so. This is a clear net-loss RFC if I've ever seen one. I'm saying that as someone who (like most of you) never uses short tags, but at the same time is not missionary against those who are and have been peacefully using them for potentially decades. I do think that these counterpoints should be represented in the RFC, as many folks vote on RFCs without regularly reading all messages on internals@. I'll be happy to add them (of course, in a condensed summarized fashion). Thanks, Zeev
