Re: [RFC] [VOTE] Deprecate PHP's short open tags, again
| From: | Robert Korulczyk | Date: | Wed, 07 Aug 2019 20:12:11 +0000 |
| Subject: | Re: [RFC] [VOTE] Deprecate PHP's short open tags, again | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-106426@lists.php.net to get a copy of this message | ||
> 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