PHP: rfc:counterargument:deprecate_php_short_tags

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Counterargument to Deprecate Short Tags RFC V2 ======
  * Date: 2019-08-06
  * Author: Zeev Suraski, zeev@php.net


===== Introduction =====

An proposal has been made to deprecate PHP's short tags syntax.  The proposal was first made available in [[https://wiki.php.net/rfc/deprecate_php_short_tags|V1 here]], and a newer version was later made available in [[https://wiki.php.net/rfc/deprecate_php_short_tags_v2|V2 here]].  The goal of this page is to provide a counterargument for this proposal, or in other words, to explain why we should not be deprecating this syntax.


==== Overview ====

The motivation for removing short tags as it is illustrated in the V2 RFC is quite weak.  Essentially - it does not present //**any**// new motivations that did not exist 20+ years ago, when this syntax was first introduced.  At the time, all the different potential opening and closing tags were heavily discussed, and all the implications - including the ones brought up by the deprecation RFC - were already known.  There is no new 'evidence' available here.

It's certainly possible to argue that the wrong decision was made back then - but it's very difficult to justify a position claiming that the situation is so bad that we must now remove this syntax - even though nothing about the underlying dry facts has changed.

The one thing that did change, which makes it even more difficult to justify this deprecation, is that unlike back then, when PHP was rounding error in terms of language popularity, today - it is one of the most widely used languages in the world.  This means that even if only a small subset of PHP developers are using this syntax - this deprecation is going to affect hundreds of thousands of people (20 years ago, it would affect virtually no one).

==== Analyzing The Motivations For Deprecation ====

=== Motivation #1: Short tags are not portable ===

Short tags are controlled by an INI setting, and are consequently not portable.  In addition, code using short-tags that's deployed on a server that has short tags disabled, will leak source code.


=== Counterpoint: Short tags were never meant to be portable ===

Short tags were, from the get-go, //**never meant for being used in portable code to begin with**//.  After over 20 years in the wild, this is very much a known quantity that surprises hardly anyone.  From the very beginning, when the discussion about what the tags would look like in PHP 3, it was clear it will be possible to disable the processing of short tags (more on that below), and that they would consequently not be usable in portable code.

Virtually all (if not literally all) PHP-based projects that are meant for redistribution - be they apps or frameworks - have rules that prohibit the use of short tags.  Short tags are used, de-facto, exclusively for non-portable code by people and companies that have complete control over their stack.

In reality, deprecating short tags does not have any meaningful contribution to making PHP codebases more portable - the ones who need to be portable are already not using this syntax, and the ones which are not - aren't meant for distribution to begin with.



=== Motivation #2: Short tags interfere with XML ===

Short tags are not compatible with XML.  XML uses <?xml ... ?> syntax, and therefore does not play nicely with servers that have short_tags enabled.

=== Counterpoint ===

This is precisely as true today as it was back in 1997-1998 when the tags for PHP were initially discussed.

With one big difference - back in the late 90's, XML appeared to be the future of anything and everything - from configuration files, through transport protocols and all the way to databases.  Fast forward 20+ years later - XML is not nearly as important today as people thought it would be, or even as it was back then.  XML is rarely the first choice for almost any use case - other formats - JSON, YAML, etc., which are fully compatible with short tags - are preferable in almost all cases.

To place more weight on XML incompatibility today than we did 20+ years ago (or any weight at all, for that matter) - seems awfully anachronistic.


=== Motivation #3 (withdrawn):  This will simplify the parser ===

In V1 of the RFC, an assertion was made that deprecating short tags will somehow help simplify PHP's parser.  This was factually incorrect - short tags do not affect the parser of PHP at all, and have no impact on neither performance nor the complexity of the PHP codebase one way or another.


==== The Case For Keeping Short Tags ====

There are four main reasons for keeping short tags.

=== Reason #1:  There's no reason to remove them ===

By now, it should be clear that nothing happened since the late 90's that should make us radically change our minds regarding the negative impact of having short tags in the language.  If anything, it's a lot less of an issue today than it was 10 or 20 years ago (given the declining popularity of XML).

As the saying goes - "if ain't broke - don't fix it".

=== Reason #2:  Short tags are de-facto opt-in ===

Even though short tags are enabled by default in most PHP binaries - in practice, they are disabled by default via configuration in virtually all mainstream PHP distributions.  This includes PHP in all mainstream Linux distros, XAMPP, macOS - and any distribution that uses one of the recommended INI files.

In practice, it means that users who want to use short tags need to take a concrete step to enable them - making it a lot less likely that they would be using them unintentionally in code that is meant to be portable.

=== Reason #3:  Removing short tags would bring needless headache to our users ===

For users of short tags, deprecating that syntax gives them a 100.0% needless headache.  As illustrated above - these are not people who care about portability, or they would have figured out by now that they shouldn't be using that syntax.  It's not that now that short tags are no longer available - they would suddenly start distributing their code, just because it can theoretically run on any server out there.

Put yourself in the shoes of a user or company that has been using short tags for their internal projects for the last decade, and are now forced to spend time and money in order to run be able to run your app on PHP 8 - for **absolutely no gain**.  What do we tell them when they ask why we did it?  "We changed our mind after 20 years even though the case against it is weaker?"  There's simply no good answer.

=== Reason #4:  Removing short tags would slow down migration to newer versions of PHP ===

PHP, like many other packages and languages - suffers from a long tail of users that are running on older versions for a variety of reasons.  One of the key reasons is the complexity of upgrading.  With this deprecation - we're making it more difficult for users to stay current, for no gain.  As it is well within the consensus that it is our interest for users to upgrade as quickly as possible to newer versions (if only for security reasons) - breaking compatibility in such a wide scale for no gain is a bad bargain.

==== Additional Thoughts ====

Most of the people who are going to vote on this RFC are not users of short tags.  I'm included on that list - I never use short tags in any PHP code that I write, and as far as I recall - I never have.

It is important to stress that this is not the question at hand.  The question we should be asking ourselves isn't whether we think short tags are a good idea, or whether we will be affected by removing them.  The question we should be asking ourselves is whether we think short tags is so catastrophically bad - that it's worth to put hundreds of thousands of people through additional pain when upgrading.  The question we should be asking ourselves is whether the situation changed so dramatically - that we should now remove a feature we introduced 20 years ago, even though nothing about the pros and cons of that feature changed.

By definition of its nature, the internals@ mailing list tends to attract developers who are at the more at the forefront of PHP development than the PHP userbase at large - for quite obvious reasons.  We should be thinking about the //entire userbase//, including parts of the userbase that are under-represented on internals@ - but are still very much an important part of the PHP ecosystem.  I believe that the vast majority of the substantial number of folks who voted against the V1 of the deprecation RFC, did so because of that - and not because they use or like short tags - presumably none of them do.


==== Summary ====

Breaking compatibility should have an exceptionally good case, with tangible, strong gains associated with it.  This is even more important when a proposed deprecation affects a large number of users in a substantial way.  The gains associated with the deprecation should far outweigh the negative impact associated with the introduction of the deprecation itself.

Deprecating short tags, as illustrated in this counterargument, brings us virtually no value at all.  It does, however, introduce very significant breakage for a wide range of users - for whom it will be very difficult (read: impossible) to explain why we made them go through this headache to begin with.

Our time, and even more so - the time of our users -  is much better spent elsewhere.
Page Tools
