Re: [PHP-DEV] Remove alternative PHP tags

[email protected] (Wim Godden)
Newsgroups php.internals
Organization Cu.be Solutions
Message-ID <[email protected]>
On 10/09/2014 3:32, Andrea Faulds wrote:
>
> 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.

Maybe it's sufficient to add this as an additional check (sniff) to 
PHPCompatibility, so we can automate the detection of these tags and 
their deprecation/removal. It won't auto-convert them, but for the few 
people using them, an auto-convertion script that works in all cases and 
never breaks code would be a lot more work to write than those people 
replacing the tags ;-)

Wim
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.