rfc:counterargument:deprecate_php_short_tags

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
Last revisionBoth sides next revision
rfc:counterargument:deprecate_php_short_tags [2019/08/05 22:42] – created zeevrfc:counterargument:deprecate_php_short_tags [2019/08/05 23:08] – Add another reason to keep short tags zeev
Line 12: Line 12:
 ==== Overview ==== ==== 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 known back then.  There is no new 'evidence' available here.+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 it'so bad that it must be removed today - even though nothing about the dry facts changed.+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 position, 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.  Even if just 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).+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 ==== ==== Analyzing The Motivations For Deprecation ====
Line 27: Line 27:
 === Counterpoint: Short tags were never meant to be portable === === 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 does not surprise 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.+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) 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.+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. 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.
Line 43: Line 43:
 This is precisely as true today as it was back in 1997-1998 when the tags for PHP were initially discussed. 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.  XML is rarely the first choice for almost all use cases - other formats - JSON, YAML, etc., which are not incompatible with short tags - are preferable in almost all cases.+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. 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.
Line 55: Line 55:
 ==== The Case For Keeping Short Tags ==== ==== The Case For Keeping Short Tags ====
  
-There are two main reasons for keeping short tags.+There are four main reasons for keeping short tags.
  
 === Reason #1:  There's no reason to remove them === === Reason #1:  There's no reason to remove them ===
Line 61: Line 61:
 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). 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).
  
-"If ain't broke - don't fix it".+As the saying goes - "if ain't broke - don't fix it".
  
-=== Reason #2:  Removing short tags would bring needless headache to our users ===+=== Reason #2:  Short tags are de-facto opt-in ===
  
-For users of short tags, deprecating them gives them a 100.0% needless headache.  As illustrated above - these are not people who care about portabilityor they would have figured out by now that they shouldn't be using that syntax.  It's not that they would suddenly start distributing their code, just because it can theoretically run on any server out there.+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.  This means that in practice, 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.
  
-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?  There's simply no good answer.+=== Reason #3:  Removing short tags would bring needless headache to our users ===
  
-=== Reason #3:  Removing short tags would slow down migration to newer versions of PHP ===+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. 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.
Line 77: Line 81:
 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. 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.  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.+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.
  
-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.+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 ==== ==== Summary ====
  
-Breaking compatibility should have an exceptionally good case, with tangible, strong gains associated with it.  These gains should far outweigh the negative impact associated with the introduction of the deprecation itself.+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. 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. Our time, and even more so - the time of our users -  is much better spent elsewhere.
rfc/counterargument/deprecate_php_short_tags.txt · Last modified: 2019/08/05 23:09 by zeev