> PHP is, after all, built almost entirely on extensions. Those extensions can > either be there, or not, enabled in the INI, or not. Do we consider code > written containing functions from mysqli, gd or zip (just to name a few) to > be non-portable because we can omit them from the INI (or just not install > them).
These are completely different things. In case of extensions, you can check whether the extension is installed, you can react on lack of it, and you can require extension as part of composer constraints (sometimes you can just use polyfill). And at worst case, you will get a fatal error that will tell you that there is something wrong with your code/environment. Neither of it is true for short tags - your code is just silently displayed. And you can't do anything about it, because you're code is no longer a code. > IMHO short tag removal has one major thing going for it, consistency, and by > extension, predictability. > > That's it. For me, the main reason to remove short tags are code leaks. As long as there will be an option to disable short open tags support, there will be code leaks. Now there is a chance to remove one source of WTFs in PHP and end this code leaks problem once and for all. The migration may be problematic for fraction of applications, but at least this is a one-time process, well documented and preceded by a long deprecation period. The alternative is current state when code leaks just unexpectedly pop out without any warning and explanation (exception "It's PHP, deal with it"). Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
