# [RFC] [VOTE] Deprecate PHP's short open tags - Thread: https://externals.io/message/105201 - Original archive: https://news-web.php.net/php.internals/105201 - Started by G. P. B. on 2019-04-10T10:43:42+00:00 - Messages: 94 - RFC: PHP RFC: Deprecate short open tags, again (Declined) — https://externals.io/rfc/deprecate_php_short_tags_v2.md - RFC: Deprecate PHP's Short Open Tags (Obsolete) — https://externals.io/rfc/deprecate_php_short_tags.md - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/105201.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #105201 — G. P. B. — 2019-04-10T10:43:42+00:00 URL: https://externals.io/message/105201#105201 Hello Internals, As there have been no further comments the voting for my RFC [1] to deprecate PHP's short open tags has started and will run for two (2) weeks. Best regards George P. Banyard [1] https://wiki.php.net/rfc/deprecate_php_short_tags --- ## #105226 — netmo.php@gmail.com — 2019-04-10T21:49:50+00:00 URL: https://externals.io/message/105201#105226 Finally!!! everybody will be able to parse my xml files with embedded php!!!!1!1 if I ever wrote one!!! Sorry for the sarcasm, please don't consider this as a personal attack. The whole community (not just you) considers short open tags poison because not XML-compatible... while they use stuff like twig, which is also not XML-compatible. This is just beyond my understanding. But sure, let's keep vilifying this kind stuff and pretend they are the root cause of PHP's bad rep. Sorry again for the negativity. --- ## #105227 — M. W. Moe — 2019-04-10T22:54:44+00:00 URL: https://externals.io/message/105201#105227 deprecate short closing tag > Finally!!! everybody will be able to parse my xml files with embedded > php!!!!1!1 if I ever wrote one!!! > > Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible. > > This is just beyond my understanding. > > But sure, let's keep vilifying this kind stuff and pretend they are the > root cause of PHP's bad rep. > > Sorry again for the negativity. --- ## #105232 — Robert Korulczyk — 2019-04-11T08:12:09+00:00 URL: https://externals.io/message/105201#105232 > Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible... This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source code leaks after moving application to a different environment. Using Finally!!! everybody will be able to parse my xml files with embedded > php!!!!1!1 if I ever wrote one!!! > > Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible. > > This is just beyond my understanding. > > But sure, let's keep vilifying this kind stuff and pretend they are the > root cause of PHP's bad rep. > > Sorry again for the negativity. --- ## #105235 — Stephen Reay — 2019-04-11T08:50:18+00:00 URL: https://externals.io/message/105201#105235 > > > The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible. I can’t say I’ve run into the XML issue in a real environment, but IMO the big ‘problem’ is that they can be disabled, so they can’t be relied upon for anything being distributed outside your own direct control. Also for the record, *I* don’t use Twig (The one thing no one can deny is php’s power as a markup templating language.. and then people don’t use it directly? Insanity.) Cheers Stephen --- ## #105236 — Peter Cowburn — 2019-04-11T10:14:06+00:00 URL: https://externals.io/message/105201#105236 > Hello Internals, > > As there have been no further comments the voting for my RFC [1] to > deprecate PHP's > short open tags has started and will run for two (2) weeks. > Firstly, I apologize for not mentioning this before the vote was opened. Does the primary (it's probably not fair to call it that, for this RFC) vote include changing the default (php -n) from On to Off? That's what is specified in the very concise proposal section, so it seems reasonable to assume it's the case, but I just want to be sure since the actual vote question doesn't mention changing the default value. With the current state of voting, it is looking like we could end up such that we don't deprecate (and disable by default, maybe) the feature, but jump straight to removing it. That's not usually how feature removal works. It would've been better, IMO, to just take the proposal ("Deprecate and disable short_open_tag in PHP 7.4 and remove PHP's short open tags in PHP 8.0.") and make that a yes/no vote. Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags --- ## #105237 — G. P. B. — 2019-04-11T10:27:48+00:00 URL: https://externals.io/message/105201#105237 > > > > > > […] > > Firstly, I apologize for not mentioning this before the vote was opened. > > Does the primary (it's probably not fair to call it that, for this RFC) > vote include changing the default (php -n) from On to Off? That's what is > specified in the very concise proposal section, so it seems reasonable to > assume it's the case, but I just want to be sure since the actual vote > question doesn't mention changing the default value. > > With the current state of voting, it is looking like we could end up such > that we don't deprecate (and disable by default, maybe) the feature, but > jump straight to removing it. That's not usually how feature removal > works. It would've been better, IMO, to just take the proposal > ("Deprecate and disable short_open_tag in PHP 7.4 and remove PHP's short > open tags in PHP 8.0.") and make that a yes/no vote. > Hello Peter, For changing the default from On to Off it more something I realised during the implementation of the patch that the in-engine default is "On", which I found to be unexpected (probably because the doc says it's only enabled with a compile flag) so I changed it. But the default could stay the same as I'm starting to realise that with current state of voting we are getting kind of a mess of a split vote as you said. It would have been nice that someone would have noticed the problems with the voting structure before I start it but not to sure how to proceed. I don't know if people vote against the deprecation notice in PHP 7.4 as the default value changes because if this is the case maybe leaving the default as is and only deprecating would be better? Also I do agree that having deprecation notices before a feature removal is wise but from my understanding the RFC which removed the ASP tags also didn't have deprecation notices, so there is already a precedent for removing features without warning (not that I agree with it). So not sure how to proceed ATM and some more feedback would be probably necessary as it is my first RFC. Best regards George P. Banyard --- ## #105244 — Thomas Hruska — 2019-04-11T15:36:51+00:00 URL: https://externals.io/message/105201#105244 > > […] > > This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source > code leaks after moving application to a different environment. Using external tool to enforce this. I wouldn't say it is the ONLY safe way. Turning it on permanently would also solve the problem and there's also allowing ' Turning it on permanently would also solve the problem Well, yes, although it creates "another way of doing the same thing". So far PHP was on a way to remove redundant tags. Permanently enabling of short open tags looks like a move in the opposite direction. Personally, I'm surprised by the controversy around this change. So far it was an obvious anti-pattern for me, and never seen anybody who was aware of the consequences of using > > […] > > I wouldn't say it is the ONLY safe way.  Turning it on permanently would also solve the problem and there's also allowing ' as a permanent always-on option.  (Native XML compatibility is a complaint, not a requirement of a language.  XML is also basically dead in my corner > of the PHP universe, only ever cropping up on very rare and very confused occasions.) > > It's going to be interesting to see how many people who rely on and *prefer* using short open tags in internal systems come out of the woodwork when > PHP 7.4 and 8 drops.  Maybe I'm the only one who likes saving a few characters here and there and thinks code is more readable without the verbose tag. > > The vote is on the knife's edge of passing/failing at the moment and could go a couple of unusual directions as already noted elsewhere. This is > probably the most interesting RFC *vote* to happen in a long while. --- ## #105252 — Reinis Rozitis — 2019-04-11T19:48:27+00:00 URL: https://externals.io/message/105201#105252 > From: Robert Korulczyk [mailto:robert@korulczyk.pl] > > Personally, I'm surprised by the controversy around this change. So far it was an > obvious anti-pattern for me, and never seen anybody who was aware of the > consequences of using Hello list, > I assume this is only about I do not see this distinction mentioned in the RFC, perhaps I missed it? I > think it would be useful to make this explicit, to avoid possible > confusion. > > G. P. B. schrieb am Mi., 24. Apr. 2019, 13:29: > > > […] > This is indeed only for the Sent: Wednesday, April 24, 2019 2:29 PM To: PHP internals Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags Hello Internal, The two weeks of voting have now ended. The results are 38 for and 18 against (total 56) for the primary vote to deprecate PHP's short open tag in PHP 7.4. This passes in favor with 68%. The results are 42 for and 15 against (total 57) for the secondary vote to remove PHP's short open tag in PHP 8. This passes in favor with 74%. Thanks for everyone who voted on this issue. Best regards George P. Banyard --- ## #105372 — Lester Caine — 2019-04-24T14:00:25+00:00 URL: https://externals.io/message/105201#105372 > A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache. This is yet another negative move in my forward planning and just another cross against even bothering with PHP8 ... and PHP7.4 is only going to complain about things so while I've not even started testing on PHP7.3, that is likely to be the last version of PHP I will be using ... once all the warnings are dealt with on PHP7.2 ... I don't think even the carrot of 'JIT' this time trumps being beaten around the head with more and more BC changes we will to have to manage and adding 'php' to every A 68% majority which barely clears the 2/3 requirements for something as > fundamental as that - with so many core devs against it - we'll deserve all the > criticism that will be coming our way in 7.4/8.0 from end users wondering why > we needlessly broke their apps and made migration a bit more of a headache. It's quite interesting to check the karma levels for the voters (might be on a slippery slope here but it feels a bit unfair that someone with just a documentation karma (or no karma at all (at least according to wiki.php.net)) has the same weight on a core option getting removed). p.s. at least for the deprecation stage for 7.4 the revert patch is simple rr --- ## #105374 — Chase Peeler — 2019-04-24T14:35:30+00:00 URL: https://externals.io/message/105201#105374 > > > […] > fundamental as that - with so many core devs against it - we'll deserve all > the criticism that will be coming our way in 7.4/8.0 from end users > wondering why we needlessly broke their apps and made migration a bit more > of a headache. > > This is yet another negative move in my forward planning and just > another cross against even bothering with PHP8 ... and PHP7.4 is only > going to complain about things so while I've not even started testing on > PHP7.3, that is likely to be the last version of PHP I will be using ... > once all the warnings are dealt with on PHP7.2 ... I don't think even > the carrot of 'JIT' this time trumps being beaten around the head with > more and more BC changes we will to have to manage and adding 'php' to > every all the other attempts at removing descriptive text elsewhere. > > Total files scanned: 20,767 Total lines scanned: 4,013,170 Total short open tag references: 6,787 Total files w/ short open tag references: 1,665 If I get started now, maybe I can have everything fixed by the time 8.1 is released. > -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - https://lsces.co.uk > EnquirySolve - https://enquirysolve.com/ > Model Engineers Digital Workshop - https://medw.co.uk > Rainbow Digital Media - https://rainbowdigitalmedia.co.uk > > -- > > > > -- Chase Peeler chasepeeler@gmail.com --- ## #105375 — Stephen Reay — 2019-04-24T14:36:06+00:00 URL: https://externals.io/message/105201#105375 > > > > > […] > > This is yet another negative move in my forward planning and just another cross against even bothering with PHP8 ... and PHP7.4 is only going to complain about things so while I've not even started testing on PHP7.3, that is likely to be the last version of PHP I will be using ... once all the warnings are dealt with on PHP7.2 ... I don't think even the carrot of 'JIT' this time trumps being beaten around the head with more and more BC changes we will to have to manage and adding 'php' to every > -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - https://lsces.co.uk > EnquirySolve - https://enquirysolve.com/ > Model Engineers Digital Workshop - https://medw.co.uk > Rainbow Digital Media - https://rainbowdigitalmedia.co.uk > > -- > > > Of all the things to ‘refuse to upgrade’ over this seems pretty silly. There are multiple tools that will automatically fix this across an entire codebase in seconds. Heck, a sed 1 liner would do it if you want to DIY it. --- ## #105376 — Lester Caine — 2019-04-24T14:56:35+00:00 URL: https://externals.io/message/105201#105376 > Of all the things to ‘refuse to upgrade’ over this seems pretty silly. There are multiple tools that will automatically fix this across an entire codebase in seconds. Heck, a sed 1 liner would do it if you want to DIY it. Another nail rather a reason it it's own right, and I've looked at these 'automatic tools' and until there is one that does not enforce their own views of code style they are just another nail ... it's bad enough when tidy TABBED code gets messed up by someone replacing them all with multiple spaces because that is 'the proper way to do it' ... this is long established coding style issue not simply automatic edits to code that IS working perfectly already. It does not 'fixing' simply because some people don't like it ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk --- ## #105377 — Peter Kokot — 2019-04-24T14:56:49+00:00 URL: https://externals.io/message/105201#105377 Hello, > > Hello Internal, > > The two weeks of voting have now ended. > The results are 38 for and 18 against (total 56) for the primary vote to > deprecate PHP's short open tag in PHP 7.4. > This passes in favor with 68%. > > The results are 42 for and 15 against (total 57) for the secondary vote to > remove PHP's short open tag in PHP 8. > This passes in favor with 74%. > > Thanks for everyone who voted on this issue. > > Best regards > > George P. Banyard > > > […] Great! It was about time this got removed. And it is a perfect timing also - PHP 8.0 when BC breaking changes can be done. Thank you so much for moving this forward. People who are thinking of supporting some legacy applications on the upcoming PHP 8 will be unfortunately a bit surprised with all the removed features and will have other bigger issues adjusting their code compared to a really simple replace of > > If I get started now, maybe I can have everything fixed by the time 8.1 is > released. Two characters less than this sentence of yours is a 1-liner find/sed script to replace all ` > > I've looked at these 'automatic tools' and until there is one that does not enforce their own views of code style they are just another nail While the pre-build rules may not be what you want - something like PHP_CodeSniffer will let you just run a single ‘sniff’ type by passing it’s name. Or use an IDE that has built-in support for inspections/fixing like this, or, as I said, run sed over your project files. Replacing ‘ wrote: > > > […] > is > > […] > > > Two characters less than this sentence of yours is a 1-liner find/sed > script to replace all ` > > > > > > > […] > > > Two characters less than this sentence of yours is a 1-liner find/sed script to replace all ` Would you really feel confident doing a blind find/replace on 6,000+ instances? It’s hardly “blind”. This is what version control is for. You make a change, and then either view the diff locally, and/or commit/push it, and ask others to help review the diff. I literally just ran the script referenced above on a client project, eyeballed the diff, and committed the changes it made to a branch. Once I’m not in the middle of anything I’ll review it again and then merge it. > > what about > What if I utilize a 3rd party library that, while no longer support, works fine, but is now broken for no other reason than the fact that You do the same thing as if the library had a security issue or some other bug. If it’s unsupported, you have to support it, or you have to find a replacement. It’s not like you’re dealing with a compiled module that you can’t edit. Run the same fix for short tags on the library. > I don't trust mass find/replace tools like php-cs-fixer. Some of our legacy code is really ugly. Auto-formatting with PhpStorm will break it. I don't mind using an interactive tool, but that means I have to sit there and hit Y or N for 6,787 instances. Some of them will probably require me to actually open the file up and check out the surrounding context as well. And, what happens if I miss one? I run the risk of code leak. If auto formatting ‘breaks’ your code, you have a bigger problem than short tags. > > I think it's great that many of you have code bases that are in pretty good shape and this change isn't going to have much of an impact on you. That's not my case, though. It's not the case for a LOT of people. I'm not against BC breaks - even major ones - if they are justified. I have yet to see any good justifications for such a massive BC break. > > The fact is that this change WILL prevent a lot of people from being able to upgrade to 8.0 in a timely manner. Anyone that has to justify spending time to prepare for an upgrade to people that don't understand the benefits of the upgrade will have an ever harder time trying to justify the extra time necessary. I also think you are going to find a good number of people that will upgrade (or use PHP for the first time) unaware of the change. They'll attempt to load older code that has short tags in it. It won't work. They'll say "screw it" and use python or node. > -- > Chase Peeler > chasepeeler@gmail.com wrote: > > > […] > > wrote: > > […] > chasepeeler@gmail.com>> wrote: > > […] > 8.1 is > > […] > script to replace all ` > […] > instances? > > It’s hardly “blind”. This is what version control is for. You make a > change, and then either view the diff locally, and/or commit/push it, and > ask others to help review the diff. > > I literally just ran the script referenced above on a client project, > eyeballed the diff, and committed the changes it made to a branch. Once I’m > not in the middle of anything I’ll review it again and then merge it. > > How big of a project? How many changes? You really think 6,787 changes among 1,656 files can just be eyeballed? > > […] > in my code, though. > > So change the pattern to replace ` equals sign. > > > […] > works fine, but is now broken for no other reason than the fact that no longer supported? Whether I should be using that library or not is > irrelevant. The fact is, I am, and the fact that I won't be able to use it > in 8.0 is a barrier to me upgrading. > > […] > > You do the same thing as if the library had a security issue or some other > bug. If it’s unsupported, you have to support it, or you have to find a > replacement. It’s not like you’re dealing with a compiled module that you > can’t edit. Run the same fix for short tags on the library. > > All valid options. Doesn't change the fact that it's more code to update meaning more time required to prepare for the upgrade. > > […] > legacy code is really ugly. Auto-formatting with PhpStorm will break it. I > don't mind using an interactive tool, but that means I have to sit there > and hit Y or N for 6,787 instances. Some of them will probably require me > to actually open the file up and check out the surrounding context as well. > And, what happens if I miss one? I run the risk of code leak. > > If auto formatting ‘breaks’ your code, you have a bigger problem than > short tags. > > I never said that our code was good. Most of our legacy code isn't ever touched. It's a mess of 10k+ line spaghetti files. It works, and until we are able to replace it, we just leave it alone. Now we are forced to go in there and mess with it for something that doesn't even pertain to the functionality of our application. Also, you didn't address the issue of missed instances. There is no way to be 100% sure any automated or manual process of replacing the tags will get everything. One of the justifications for this RFC was the possibility of code leak if code with short tags is loaded in an environment that has short tags disabled. We've decided to fix that by making sure that any code with short tags will DEFINITELY leak code. That makes a lot of sense. Eyeballing a diff isn't going to help you find missed instances either. > > […] > good shape and this change isn't going to have much of an impact on you. > That's not my case, though. It's not the case for a LOT of people. I'm not > against BC breaks - even major ones - if they are justified. I have yet to > see any good justifications for such a massive BC break. > > […] > able to upgrade to 8.0 in a timely manner. Anyone that has to justify > spending time to prepare for an upgrade to people that don't understand the > benefits of the upgrade will have an ever harder time trying to justify the > extra time necessary. I also think you are going to find a good number of > people that will upgrade (or use PHP for the first time) unaware of the > change. They'll attempt to load older code that has short tags in it. It > won't work. They'll say "screw it" and use python or node. > > […] > > It's not that I'm against the idea of abolishing short tags. It's that I don't feel the problems abolishing them will cause are justified by the reasons given for abolishing them. No matter how easy you think it is to deal with this, it won't change the fact that it's going to be a barrier to upgrading for a lot of people. It's going to have a negative impact on 8.0 adoption. It's going to lead to a larger number of people running PHP versions that have reached EOL. In the end, it's going to hurt the market share and reputation of PHP. -- Chase Peeler chasepeeler@gmail.com --- ## #105383 — Thomas Bley — 2019-04-24T16:03:11+00:00 URL: https://externals.io/message/105201#105383 Hello, I understand that breaking changes always need extra work, but in this case I think it's a quick change. On my code base (mostly legacy with 1.8m lines), I ran this and got 10 matches to check: grep -rin " vsuraski@gmail.com hat am 24. April 2019 um 15:41 geschrieben: > > > FWIW, > > I think it's a bad decision, made against the thoughts of clear majority of core developers - and for hardly a good reason. I believe it illustrates very well why we need to properly define our voting eligibility rules, and I hope someone would be up to the challenge of tackling it (I decided not to pursue it further after the 'abolish' RFC(s)). > > A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache. > > My 2c. > > Zeev > > > -----Original Message----- > From: G. P. B. > Sent: Wednesday, April 24, 2019 2:29 PM > To: PHP internals > Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags > > Hello Internal, > > The two weeks of voting have now ended. > The results are 38 for and 18 against (total 56) for the primary vote to deprecate PHP's short open tag in PHP 7.4. > This passes in favor with 68%. > > The results are 42 for and 15 against (total 57) for the secondary vote to remove PHP's short open tag in PHP 8. > This passes in favor with 74%. > > Thanks for everyone who voted on this issue. > > Best regards > > George P. Banyard --- Next page: https://externals.io/message/105201.md?page=2