Hi! > Every app will have different things to fix. So saying that this > particular change will break the internet is not realistic without any > numbers. If PHP is on a course to fix the BC break strategy then good
I am not saying it will break the internet. Nobody does. What I am saying it creates a huge and serious risk (both operational and security) for people upgrading, and I am not sure why it is being dismissed roughly as "well, BC happens, what you gonna do..." In my opinion, it's not a kind of issue one should be dismissing. It's not a regular low-grade BC break, it's a serious and dangerous one. Probably one of the most dangerous - in its current state, as voted - among all present in the release. > even this discussion. Because, from what I think here more is that > we're discussing how to keep the short tags forever and how to remove > them as soon as possible. There is a difference in what people want I don't think dealing in absolutes here is helpful. There are more options than "ASAP" and "never". And I feel that the RFC as-is have not considered them thoroughly enough - otherwise I can not see how the issue of spilling out the source has not been handled. > removing the tags in the first place. I haven't seen any step forward > from this point yet and what kind of a different removal strategy > (compared to Nikita's suggestion) would work. Whatever removal strategy there is, it should not be "let's switch the default in 7.4, remove the whole token completely in 8.0 and let people that have <? in their code have it spilled out like groceries from a torn paperbag". I personally think that whatever meager benefit we get from the removal at the end (?xml thing? ridiculously narrow use case. parser simplification? by removing one tag out of dozens? minuscule. etc.) but if there are so many people that hate it, well, we can go ahead and work on removal. But not in the way that creates problems much worse than the current state. > I haven't seen code with short tags for such a long time now that this > is for me a problem on a scale of a fly. Because we've simply upgraded You must realize you haven't seen 99.999% of existing PHP code, and that's probably if you look at a lot of code? Massive amounts of code are not public. Massive amounts of code are using old library versions and old dependencies, a lot of them not easily upgradable to latest versions because the surrounding code is old too and newest versions break it. The fact that you personally haven't seen such code and it's not a problem for *you* doesn't mean a lot if you purport to take responsibility over the needs of millions of PHP users. Voting on RFC should not be an expression of a personal opinion and only it, if it is we have a grotesque situation where personal whims of barely 50 random people decide things for millions. This can only work if each of these people realizes the responsibility inherent in the decisions being taken and considers the impact that their vote would have not only for their personal needs, but for other users too. > know and probably won't understand fully. But, also at least now this > discussion and also RFC brought this thing out - short open tags > shouldn't be used anymore in any case. :) Because obviously a very There's a very big distance from recommending not using short tags to removing short tags from the parser. We've just voted for covering this distance in two releases. I think this would be a costly mistake. There are ways of doing it properly - Nikita's proposal could be one of them. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
