Re: [RFC] [VOTE] Deprecate PHP's short open tags, again
| From: | Kris Craig | Date: | Mon, 12 Aug 2019 08:29:21 +0000 |
| Subject: | Re: [RFC] [VOTE] Deprecate PHP's short open tags, again | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-106553@lists.php.net to get a copy of this message | ||
On Fri, Aug 9, 2019 at 6:25 AM Robert Korulczyk <robert@korulczyk.pl> wrote:
> > Disabling short tags now is done with "an explicit directive" (there has
> to be a specific ini file with a specific setting 'short_open_tag = 0').
> > Isn't this the same "situation when you create a separate file with an
> explicit directive"?
>
> No, it's not.
php.ini is outside of project responsibility
> - as a
> developer you don't really configure this in any way, your application does
> not
> have any explicit directive to disable/enable short open tags. You just
> accidentally using feature that could lead to code leak.
> In your example with engine directive you explicitly disable
> PHP engine
> by creating dedicated file for that purpose - there is no way do to this by
> accident and then does not notice it.
>
>
> > If a coder (or IDE) has written '<?', '<%' or by accident any
> > other tag
> unless tested the effect (a part of code not being parsed/executed) will be
> > exactly the same if the feature suddenly disappeared (unless the
> additional checks in the 'v2 RFC' which on the other hand would make the
> engine a
> > tiny bit slower but probably have to be implemented to avoid such
> accidents).
>
> At least the this behavior will be consistent - you will not have cases
> when code works fine on one environment and leak on another.
>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
So far, the RFC only has 55% support, which means it's not going to pass
this time, anyway, unless there's a vote shift in the next 8 days.