[RFC] [DISCUSSION] Deprecate PHP's short open tags V2

On 23 July 2019 18:54:48 BST, "G. P. B." <george.banyard@gmail.com> wrote:

Given that you've already predicted that this will be controversial, could you provide some rationale for it? Unless there's a major burden in maintaining the parser error behaviour for a few years, waiting for the next major version would seem both safer and more in line with official versioning policy. As with deprecation itself, any violation of the "no breaking changes" rule, however slight, should have an explicit justification. If I had a vote, any RFC omitting such a justification would receive an automatic "no" from me. Regards,

Hi!

Could you please explain what has changed since the last time we discussed it that makes it necessary to bring the second RFC on the same topic? Did any arguments about the dangers of removing the short tags somehow became invalid? If yes, then how? What necessitates changing the results of that RFC almost immediately after it was implemented? In the RFC, I read: Worse than that, code using short open tags deployed on a server using short_open_tag=0 will leak application code, because short open tags are silently ignored. I am not sure how it is supposed to be an argument for making such behavior the default. Could you explain?

Realistically, a non-negligible proportion of users will jump from PHP 7.x to 8.1 or 8.2; so that having the parse error behaviour in 8.0 only is in no way safer for them. It is more reasonable to keep the parse error behaviour for all 8.x versions. —Claude

While this RFC is a much better way of deprecating the feature (looking at the previous votes it most likely will happen), the reasoning/text (main point) is still odd: - if the code author wants a portable code he HAS the necessary control over it and can always follow the coding guidelines and write it using '<?php' - contrary the control/option is taken away from the server administrator (the deployment environment provider) that if there is a project/code that uses short tags there is no way to support that anymore besides altering the code (for what he might not have the necessary control). rr

I continue to find motivations #1 and #3 utterly bizarre, especially that "open tags not being compatible with XML" is still being used as a justification. That said, the depreciation and removal process looks solid, with the exception of complete removal in PHP 8.1. I must question if people are really so desperate to use <? in plain text (for XML?) that it needs to be removed with such haste, especially as its continued existence at that point would be strictly as a security feature. If I may make one suggestion, I see the depreciation message is quite plain. One would not be stretching the bounds of reasonableness too far to suggest the creation of a dedicated page on php.net that contains a description, a link to csfixer etc, and then that link be included in the depreciation message itself.

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

[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.banyard@gmail.com> wrote:

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

As we head closer to the vote - and in light of what I said towards the end of my message in https://externals.io/message/106256#106278, as well as the points Dan articulated regarding the current issue of negative feedback not getting the same level of visibility as the RFC itself - I'd like to figure out a temp solution until we amend our rules. George - are you OK with having a section that illustrates the issues that me and some others have brought up with this deprecation in the RFC itself? Or add a link to a separate page, along the lines of what Dan proposed? Thanks, Zeev On Tue, Jul 23, 2019 at 8:55 PM G. P. B. <george.banyard@gmail.com> wrote: