[RFC] Short Open Tag deprecation V2

[Girgias]

New implementation for the Short open tag deprecation RFC.

Supersedes #3972

[nikic]

Tokenizer test change committed in b2d6d29.

[Girgias]

By the way, thanks @nikic for announcing the new implementation on internals, however, it seems no one has replied to it. So what's the plan with it?

[nikic]

If there's no objection on list we can land it.

[salarmehr]

Please don't remove short open tags. There are no practical benefits of doing this (as is even clear from its RFC) and it only would impose a cost to all legacy applications to just change the syntax of their source code to yield nothing.

[glensc]

@salarmehr: there is reasoning on rfc page (own section): https://wiki.php.net/rfc/deprecate_php_short_tags#reasoning

• The PHP documentation discourages their usage.
• PHP's short open tags clash with XML and can mean two different things depending on the INI configuration.
• PHP's short open tags depend on an INI directive and as such are non-portable.
• As such source code may leak if PHP relying on the short open tags is executed on a configuration where this isn't enabled.
• PHP's parser simplification.

from these, the strongest argument IMHO is the portability, the others all have solutions (workaround), but it's still not a big reason to drop short tags; if you need to write portable code, use <?php tag.

also, the discouragement in the documentation says that it needs to be enabled first:

PHP also allows for short open tag <? (which is discouraged since it is only available if enabled using the short_open_tag php.ini configuration file directive, or if PHP was configured with the --enable-short-tags option).

so such choice can be still preserved if having some framework/templates optimized for file size (or why the short tags)?

as for converting legacy application, PHP-CS-Fixer does the conversion pretty fine or stick to older php version.

[salarmehr]

@glensc, yep, I have had seen those "reasons". None of them is even slightly compelling. All four first mentioned reasons are essentially considering the dependence of short syntax to ini configuration. There are numerous features and extensions whose are related to ini file. Should we deprecate all?
Short tags are also enabled by default. There is no clear benefit for this RFC and it just causes issues for companies and adds an obstacle on their upgrade path. Majority of commercial product owner are reluctant to automatically change the source code.

The correct RFC should be enabling the short tag by default and advocating of using it as there is no drawback of using it. In the very very rare case of using XML and PHP together, the ini option is available.

[jrfnl]

Just a FYI as CS-Fixer is mentioned above: PHP_CodeSniffer (of course) also has a sniff for this.

The Generic.PHP.DisallowShortOpenTag.Found sniff/errorcode can detect and auto-fix short open tags.

When the ini-setting is turned off, the sniff will not auto-fix, but will still be able to detect short open tags with near 100% accuracy and will throw a Generic.PHP.DisallowShortOpenTag.PossibleFound warning instead.

[salarmehr]

@jrfnl thanks for your comment. The argument here is there is no point in introducing such an issue in the first place.

[jrfnl]

@salarmehr My comment wasn't intended for you.
I have no beef in your argument, that discussion has come and gone on the internals mailinglist and the RFC passed a while ago, so I suggest you accept the new reality.

[Girgias]

@jrnf Even a reality can be corrected, this ticket is not still a reality! It just needs some courage.

I'll just comment on that because this getting closed anyway.
Courage is facing change and not accepting the status quo. Doing that is IMHO cowardice.

Closing because RFC has been declined.

[glensc]

@Girgias can you link to the RFC decline decision? the wiki seems to vote in favor.

[cmb69]

@glensc, there had been a new RFC.

[glensc]

thansk, link to counterargument rfc as well: https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags

[salarmehr]

@glensc So glad that RFC is declined. Thanks for the link.
One missing point in favour of keeping a short tag is we have <?= ?> syntax that is in harmony with <? ?> syntax.

[jrchamp]

This is all very confusing. How can an RFC be proposed, announced, voted on, accepted, but not merged? I understand that this is version 2, which was declined, but that just means that version 1 was never superseded. Because RFC version 1 was accepted, to undo an accepted RFC or modify the RFC, there must be a new RFC that is voted on and accepted.

Note: Edited to highlight the procedural concerns which don't appear to be addressed here or in the RFCs.

[Girgias]

@jrchamp please direct your frustration to the individuals who pressured me to redo a second version of a passed RFC and consider the first one void. As I am in no way able to act open it.

Or directly the PHP internals mailing list.

[jrchamp]

Thank you @Girgias for explaining and trying to make PHP better. I have done a lot of reading of the [complete meltdown] that is occurring on the PHP Internals mailing list, so I think it's going to be some time before the group as a whole can decide on anything.

For those who have the same question as me and end up here, the result appears to be this:

1. The co-founder of Zend claims that although short_open_tag RFC v1 passed the vote, it had "catastrophic implications for upgrades - so it could not be implemented as it was written", theoretically, self-voiding.
2. short_open_tag RFC v2 did not pass the vote, causing this pull request to be declined.

Net change: None, other than turmoil in the PHP internals community.

I ❤️ all of you and I hope civility returns someday soon.

[abbychau]

@jrchamp would you mind sharing the link of the thread of the mailing list?

[jrchamp]

Hi @abbychau

Caution

The discussions get heated and hurtful soon after the results of the first vote are posted.

php-internals threads:

• [PHP-DEV] [RFC] Deprecate PHP's short open tags
• [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
• [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
• [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again