Hi internals!
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:
https://wiki.php.net/rfc/remove_alternative_php_tags
It removes <% and <script language=php> and the other variations of asp and
script tags.
Nikita
Hi internals!
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:https://wiki.php.net/rfc/remove_alternative_php_tagsIt removes <% and <script language=php> and the other variations of asp and
script tags.Nikita
My opinion is that anyone relying on these in a modern version of the
language has been upgrading things the wrong way around.
No modern PHP developer relies on these as a feature of the language,
and any PHP developer relying on these almost certainly does not need
any of the new language features.
Being future facing means dropping the chaff from the past. +1
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:https://wiki.php.net/rfc/remove_alternative_php_tags
It removes <% and <script language=php> and the other variations of asp and
script tags.
Isn’t this a bit of a needless BC break? Not very nice on people with such codebases. It’s also worth pointing out that people might be using these to get around the XML <? issue (granted, you can disable short tags).
I’d vote for this if you wrote a convertor script to help people migrate. Otherwise I think we’re just being unfair on people who used these tags.
Actually, I’d like to see a Python 2to3-esque tool in general for PHP 7. The easier we make the migration, the more likely people will do it.
--
Andrea Faulds
http://ajf.me/
Isn’t this a bit of a needless BC break? Not very nice on people with such codebases. It’s also worth pointing out that people might be using these to get around the XML <? issue (granted, you can disable short tags).
I’d vote for this if you wrote a convertor script to help people migrate. Otherwise I think we’re just being unfair on people who used these tags.
Actually, I’d like to see a Python 2to3-esque tool in general for PHP 7. The easier we make the migration, the more likely people will do it.
Some further thoughts after discussing with Tyrael (Ferenc) on IRC.
I initially thought that I’m not really against removing them really, but I think we should have a script to convert them first. Because someone, somewhere, is gonna need it.
But then I’ve thought more about it. I’m usually OK with certain BC breaks, I just don’t like this specific one. It doesn’t affect me, but, well, I don’t see the point. It doesn’t really help language consistency or anything, (OK, sure, only two sets of delimeters now, but it’s not a big deal like some other things are), and you’ll force people to update every file in their codebase if they’re affected, assuming people who use alternative tags use them everywhere. There’s also a security issue here. If someone uses PHP 7 with a codebase that has these alternative tags, your code is now visible to users instead of the output, which might include configuration details like database passwords or password hash salts. It’s also possible that people won’t notice this is happening if they only used these alternative tags in a few obscure places.
I wonder if, really, we might be better off keeping them around and just outputting E_DEPRECATED. If we do get rid of them in 7, we should have 5.7 deprecate them.
Andrea Faulds
http://ajf.me/
Isn’t this a bit of a needless BC break? Not very nice on people with
such codebases. It’s also worth pointing out that people might be using
these to get around the XML <? issue (granted, you can disable short tags).I’d vote for this if you wrote a convertor script to help people
migrate. Otherwise I think we’re just being unfair on people who used these
tags.Actually, I’d like to see a Python 2to3-esque tool in general for PHP 7.
The easier we make the migration, the more likely people will do it.Some further thoughts after discussing with Tyrael (Ferenc) on IRC.
I initially thought that I’m not really against removing them really, but
I think we should have a script to convert them first. Because someone,
somewhere, is gonna need it.But then I’ve thought more about it. I’m usually OK with certain BC
breaks, I just don’t like this specific one. It doesn’t affect me, but,
well, I don’t see the point. It doesn’t really help language consistency or
anything, (OK, sure, only two sets of delimeters now, but it’s not a big
deal like some other things are), and you’ll force people to update every
file in their codebase if they’re affected, assuming people who use
alternative tags use them everywhere. There’s also a security issue here.
If someone uses PHP 7 with a codebase that has these alternative tags, your
code is now visible to users instead of the output, which might include
configuration details like database passwords or password hash salts. It’s
also possible that people won’t notice this is happening if they only used
these alternative tags in a few obscure places.I wonder if, really, we might be better off keeping them around and just
outputting E_DEPRECATED. If we do get rid of them in 7, we should have 5.7
deprecate them.Andrea Faulds
http://ajf.me/--
I think Andrea raises a valid point about BC. I agree that those old tags
should go, but I'd suggest we target that removal for PHP 7 and just add a
deprecated flag on 5.x.
--Kris
I think Andrea raises a valid point about BC. I agree that those old tags
should go, but I'd suggest we target that removal for PHP 7 and just add a
deprecated flag on 5.x.
nobody suggested removing them in 5.x, and while I agree that adding a
deprecated notice before the removal would be a good thing, but currently
there is no 5.7, and when we discussed it back when merging phpng to
master, it seemed that many people felt that it shouldn't be one before the
release of PHP7, so I'm not sure how could someone incorporate this idea
into the rfc.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I initially thought that I’m not really against removing them really, but
I think we should have a script to convert them first. Because someone,
somewhere, is gonna need it.
I have added a small script for porting prehistoric tags, see
https://wiki.php.net/rfc/remove_alternative_php_tags#porting_tool
But then I’ve thought more about it. I’m usually OK with certain BC breaks,
I just don’t like this specific one. It doesn’t affect me, but, well, I
don’t see the point. It doesn’t really help language consistency or
anything, (OK, sure, only two sets of delimeters now, but it’s not a big
deal like some other things are), and you’ll force people to update every
file in their codebase if they’re affected, assuming people who use
alternative tags use them everywhere.
In the context of a recent discussion on this list about the nature of
different BC break, this is the very best BC break that is possible. It is
trivial to detect statically and it is trivial to fix statically. Nobody
needs to "update every file in their codebase" manually.
There’s also a security issue here. If someone uses PHP 7 with a codebase
that has these alternative tags, your code is now visible to users instead
of the output, which might include configuration details like database
passwords or password hash salts. It’s also possible that people won’t
notice this is happening if they only used these alternative tags in a few
obscure places.
I am amenable to adding the asp_tags option to the
http://lxr.php.net/xref/PHP_TRUNK/main/main.c#2339 list, which will trigger
a fatal error on startup if it is enabled - that should make sure that
anyone using those is aware of the problem (we can also add it to the
deprecated list in 5.7, should we have such a release). Doesn't apply to
I have added a small script for porting prehistoric tags, see https://wiki.php.net/rfc/remove_alternative_php_tags#porting_tool
That’s great! To clarify: This only works on 5.x where asp_tags is available, yes?
I am amenable to adding the asp_tags option to the http://lxr.php.net/xref/PHP_TRUNK/main/main.c#2339 list, which will trigger a fatal error on startup if it is enabled - that should make sure that anyone using those is aware of the problem (we can also add it to the deprecated list in 5.7, should we have such a release). Doesn't apply to <script> of course.
That’d partly solve the problem.
Perhaps we could make the lexer continue to lex <script> but throw an E_COMPILE_ERROR? Then I’d be happy.
Andrea Faulds
http://ajf.me/
Hi Nikita
2014-09-10 0:08 GMT+02:00 Nikita Popov nikita.ppv@gmail.com:
Hi internals!
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:https://wiki.php.net/rfc/remove_alternative_php_tags
Great RFC, +1. No need to defend these old nordic legacy features,
afair <script> was mainly added for FrontPage back in the day, and
getting rid of asp_tags also mean we have one less ini setting
affecting the language syntax which is only great.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Nikita Popov wrote:
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:https://wiki.php.net/rfc/remove_alternative_php_tagsIt removes <% and <script language=php> and the other variations of asp and
script tags.
The RFC states:
| The alternative PHP tags have never gained any significant degree of
| usage. Their usage has been discouraged since forever.
Unfortunately, it seems that the PHP manual doesn't mention that all
these PHP tags are discouraged.
http://php.net/manual/en/language.basic-syntax.phpmode.php only mentions:
| As such, while some people find short tags and ASP style tags
| convenient, they are less portable, and generally not recommended.
I wonder if there are any faithful stats regarding the usage of the
alternative PHP tags. I have never seen them in use (I have not even
been aware of the <script ...> tags), but that doesn't mean much.
--
Christoph M. Becker
Hi internals!
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:https://wiki.php.net/rfc/remove_alternative_php_tagsIt removes <% and <script language=php> and the other variations of asp
and script tags.
As a heads up, I'll start voting on this RFC tomorrow. Since the original
submission the following changes have been made:
- Addition of a script porting legacy tags to normal PHP tags.
- Throwing a core error when trying to enable asp_tags. (Same as what we
do for many other removed ini options.)
Nikita