# [RFC] Deprecate Backtick Operator (V2) - Thread: https://externals.io/message/107470 - Original archive: https://news-web.php.net/php.internals/107470 - Started by Olumide Samson on 2019-10-10T16:53:31+00:00 - Messages: 47 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/107470.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 --- ## #107392 — Nikita Popov — 2019-10-07T07:50:36+00:00 URL: https://externals.io/message/107470#107392 > Hi Internals, > > I put forward the following RFC "Deprecate Backtick Operator (V2)" for > discussion. > > https://wiki.php.net/rfc/deprecate-backtick-operator-v2 > > I believe it is at least worth a discussion as to the pros and cons of > deprecating this functionality, especially in light of the existence of > better described and more well-known functions exhibiting identical > behaviour. > > This RFC only covers the issuing a deprecation notice, and its complete > removal would be contained within a separate RFC. > Usage of backtick operator in packagist top 2k packages: https://gist.github.com/nikic/7b0afaf4d8b1a1087cdb61cd1e776594 There are 72 occurrences including duplicates. Make of that whatever you will :) Nikita --- ## #107405 — Theodore Brown — 2019-10-08T03:31:52+00:00 URL: https://externals.io/message/107470#107405 · In reply to: #107392 > > > > […] > > Usage of backtick operator in packagist top 2k packages: > https://gist.github.com/nikic/7b0afaf4d8b1a1087cdb61cd1e776594 > There are 72 occurrences including duplicates. > > Make of that whatever you will :) I did some further analysis on the output of Nikita's script. Ignoring the duplicate WordPress package, all the occurrences are in just 21 unique projects. In 8 of these, the backtick uses are exclusively in test files or other scripts not part of the library source code. Then there are 11 packages with one or two uses each, and only 2 packages with more than two occurrences. Raw numbers: https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34 Best regards, Theodore --- ## #107407 — Zeev Suraski — 2019-10-08T07:49:35+00:00 URL: https://externals.io/message/107470#107407 · In reply to: #107405 Before replying (quickly) to this, I want to point out, again, that it’s mind boggling we have to start discussing non-topics and spend time, energy and mental strength on this endless stream of out-of-the-blue deprecation proposals. > > I did some further analysis on the output of Nikita's script. > Ignoring the duplicate WordPress package, all the occurrences > are in just 21 unique projects. So in the non-representative sample of the PHP codebase at large, we have it used in roughly 1% of the packages. That’s not “just” - that’s a lot for a language as ridiculously popular as PHP is. In 8 of these, the backtick uses are exclusively in test files or other > scripts not part of the library source code. Then there are 11 packages > with one or two uses each, and only 2 packages with more than two > occurrences. > That’s another clue right there - of course it’s less likely to be found in library code, and more likely to be found in admin scripts - which are in turn less likely to be in packagist or otherwise public. That said, the key point here has nothing to do with the popularity. It has to do with the fact that nothing, absolutely nothing happened since this feature was introduced to make us even consider removing it. Each and every one of the supplied motivations for supposedly removing it existed in exactly the same way when it was introduced. Current internals@ folks having a different opinion over the exact same facts is NOT sufficient grounds for removing it or even starting a discussion about it. Something new and very substantial has to happen for us to even start having this conversation. That’s how it’s always been and that’s how it should stay. Zeev --- ## #107408 — Lester Caine — 2019-10-08T08:46:43+00:00 URL: https://externals.io/message/107470#107408 · In reply to: #107405 > In 8 of these, the backtick uses are exclusively in test files or other > scripts not part of the library source code. Then there are 11 packages > with one or two uses each, and only 2 packages with more than two occurrences. > > Raw numbers:https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34 The question that has to be asked here is how many legacy projects have actually been moved to 'new' services like github, or even use code management anyway. The vast majority of third party hosting is simply based on isolated file management and even running clean-up tools are not going to be easy. Especially where the original author who set up the website is no longer around. While some hosts are maintaining the old versions of PHP, more often these days the big players are buying up small outfits and moving customers to new setups often without adequate care. Which is why ANY unnecessary changes that need to be made as a result are just painful often without ANY gain what so ever on either side? -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk --- ## #107410 — Benjamin Morel — 2019-10-08T09:09:06+00:00 URL: https://externals.io/message/107470#107410 · In reply to: #107408 > Which is why ANY unnecessary changes that need to be made as a > result are just painful often without ANY gain what so ever on either side? One gain that's very often overlooked on this list, is teaching a better PHP to new generations. It IS confusing if PHP has more than one way to do one thing, and if one of them is considered better than the other nowadays, the other should be deprecated so that NEW code doesn't use it. Unless I missed something, nobody in this thread has mentioned REMOVING backticks, just DEPRECATING them. You don't HAVE to follow the deprecation with a removal, at least not in a near future. But by deprecating the feature, at least you're stopping the bleeding and (mostly) avoiding new code being written that uses the legacy feature. Otherwise we'll have this discussion again in 20 years, with the same outcome. — Benjamin > > > […] > occurrences. > > […] > https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34 > > The question that has to be asked here is how many legacy projects have > actually been moved to 'new' services like github, or even use code > management anyway. The vast majority of third party hosting is simply > based on isolated file management and even running clean-up tools are > not going to be easy. Especially where the original author who set up > the website is no longer around. While some hosts are maintaining the > old versions of PHP, more often these days the big players are buying up > small outfits and moving customers to new setups often without adequate > care. Which is why ANY unnecessary changes that need to be made as a > result are just painful often without ANY gain what so ever on either side? > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.uk/wiki/Contact > L.S.Caine Electronic Services - https://lsces.uk > Model Engineers Digital Workshop - https://medw.uk > Rainbow Digital Media - https://rainbowdigitalmedia.uk --- ## #107415 — Reinis Rozitis — 2019-10-08T11:02:24+00:00 URL: https://externals.io/message/107470#107415 · In reply to: #107410 > -----Original Message----- > From: Benjamin Morel [mailto:benjamin.morel@gmail.com] > > One gain that's very often overlooked on this list, is teaching a better PHP to > new generations. It IS confusing if PHP has more than one way to do one thing, Not directly related to this RFC but out of curiosity - where does this "doing the same thing in multiple ways is confusing" comes from? (I mean this as serious question) I had the impression that programming in essence is all about that - achieving/accomplishing something/the same different ways? Because then you have to question a lot of things (not saying it's a bad thing) - like for example why does heredoc <<< (or nowdoc) exist when we have =, .= (also probably won't be found in most if any popular/public projects, libraries) and so on.. (While extreme) then dropping PHP just because there are 10 other programming languages that do the same thing (or even better) also becomes an argument because it is kind of "confusing for new generations" to pick and choose which one is better (Which one is more easy? Which uses less system resources/is faster? Where do you get more salary as employee? Etc)? p.s. sorry for offtopic rr --- ## #107425 — Stanislav Malyshev — 2019-10-08T18:19:28+00:00 URL: https://externals.io/message/107470#107425 · In reply to: #107410 Hi! > PHP to new generations. It IS confusing if PHP has more than one way to do > one thing, and if one of them is considered better than the other nowadays, No it's not. At least no more than anything else in life. There's always alternatives to do something. And PHP has always been a language where having a convenient way of doing something that already has an inconvenient way to do the same has always been welcomed. > the other should be deprecated so that NEW code doesn't use it. Unless I > missed something, nobody in this thread has mentioned REMOVING backticks, This is not true, the RFC itself states: Although the deprecation notice itself will carry no backwards compatibility changes, this RFC is written with the intent that the backtick operator would eventually be removed in a later version. Did you read that part and conclude *nobody* mentioned REMOVING? How did that work? > just DEPRECATING them. You don't HAVE to follow the deprecation with a You don't have to, but the intent of this RFC is specifically stated as such. Also, there's no reason to deprecate it either, for the same reasons. There's absolutely nothing wrong with it except "it could make somebody to look in the manual, potentially, so burn it with fire!" > least you're stopping the bleeding and (mostly) avoiding new code being There's no bleeding and nothing to avoid. > written that uses the legacy feature. Otherwise we'll have this discussion > again in 20 years, with the same outcome. It would be nice if we didn't, but unfortunately I suspect we will. Sigh. -- Stas Malyshev smalyshev@gmail.com --- ## #107432 — Mike Schinkel — 2019-10-08T20:12:12+00:00 URL: https://externals.io/message/107470#107432 · In reply to: #107425 My, my this is a heated topic. I am commenting in part because I do not have a dog in this hunt. I am okay leaving it, I am okay if it is deprecated. There are other things for PHP that I care far more about than this RFC. So... I am wondering if everyone participating in this discussion would be willing to ask themselves "Is there any middle ground where I can respond in a way that is win-win for everyone involved?" rather than retreating to each other's respective corners and fighting as if to the death? If I did not know better I would think this group was filled with members of the US Congress because of the unwillingness to compromise and seek common ground. For example, would those who oppose this RFC change to support it if this was changed from: > Although the deprecation notice itself will carry no backwards > compatibility changes, this RFC is written with the intent that the > backtick operator would eventually be removed in a later version To this?: The deprecation notice will carry no backwards compatibility changes. In addition this RFC is explicitly not recommending removal of the backtick operator in a later version. To remove it — if ever desired — will require an additional RFC to be passed. Maybe the above resolves the objections against this RFC? Or maybe the above makes it useless in the minds of those who want to get rid of backtick? But this specific FRC does not matter to me The point however, is can we not work to some form of happy medium rather than everyone fighting a zero sum game? -Mike #jmtcw --- ## #107433 — M. W. Moe — 2019-10-08T20:22:48+00:00 URL: https://externals.io/message/107470#107433 · In reply to: #107432 @Mike Schinkel, a middle ground about/with silliness? there is none, for people in their right mind; should people really find/force themselves into conciliation about non-sense? I don't think so and mostly; I have no say about deprecating that; but is that a priority? does it harm anyone? someone have died from backtick infection, it must be according to some? and so on. Don't see where there is a heated topic; solely a reminder about reality and facts. Regards. > My, my this is a heated topic. > > I am commenting in part because I do not have a dog in this hunt. I am > okay leaving it, I am okay if it is deprecated. There are other things for > PHP that I care far more about than this RFC. So... > > I am wondering if everyone participating in this discussion would be > willing to ask themselves "Is there any middle ground where I can respond > in a way that is win-win for everyone involved?" rather than retreating to > each other's respective corners and fighting as if to the death? > > If I did not know better I would think this group was filled with members > of the US Congress because of the unwillingness to compromise and seek > common ground. > > For example, would those who oppose this RFC change to support it if this > was changed from: > > > […] > > > […] > > > […] > > > To this?: > > The deprecation notice will carry no backwards compatibility changes. > In addition this RFC is explicitly not recommending removal of the > backtick operator in a later version. To remove it — if ever desired — > will require an additional RFC to be passed. > > > Maybe the above resolves the objections against this RFC? Or maybe the > above makes it useless in the minds of those who want to get rid of > backtick? But this specific FRC does not matter to me > > The point however, is can we not work to some form of happy medium rather > than everyone fighting a zero sum game? > > -Mike > #jmtcw --- ## #107435 — Walter Parker — 2019-10-08T20:26:02+00:00 URL: https://externals.io/message/107470#107435 · In reply to: #107433 > @Mike Schinkel, > > a middle ground about/with silliness? there is none, for people in their > right mind; should people really find/force > themselves into conciliation about non-sense? I don't think so and mostly; > I have no say about deprecating that; > but is that a priority? does it harm anyone? someone have died from > backtick infection, it must be according to some? > and so on. Don't see where there is a heated topic; solely a reminder about > reality and facts. > > Regards. > > > > > […] > for > > […] > to > > […] > What would a happy medium be? backticks working 50% of the time? This is like someone being pregnant, either you are or you are not there is no half pregnant. Either backticks work like they have in shells for decades or they don't work. What's the point of deprecating them without a plan to remove them? A notice without future action is a bad idea, as it sets standard that some deprecation messages will not be acted upon. Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis --- ## #107436 — Lynn — 2019-10-08T20:29:27+00:00 URL: https://externals.io/message/107470#107436 · In reply to: #107432 > My, my this is a heated topic. > > I am commenting in part because I do not have a dog in this hunt. I am > okay leaving it, I am okay if it is deprecated. There are other things for > PHP that I care far more about than this RFC. So... > > I am wondering if everyone participating in this discussion would be > willing to ask themselves "Is there any middle ground where I can respond > in a way that is win-win for everyone involved?" rather than retreating to > each other's respective corners and fighting as if to the death? > Hi, My middle ground is a vote, regardless of outcome. This RFC is pretty simple, a deprecation + removal in a later patch, there's not much to compromise on the implementation. If people think a deprecation should not be done or if it's not worth it, a vote is the way to show that opinion. Pros and cons have been given and people have different opinions about those. Currently a few people on the mailing list are very vocal up to a point where it becomes obnoxious to read their replies, and others are stating that this RFC shouldn't even go into a vote. If there are enough reasons to not deprecate them, the voting process will show this and the RFC will be rejected. Regards, Lynn van der Berg PS. We need a CoC. --- ## #107437 — Mike Schinkel — 2019-10-08T20:38:03+00:00 URL: https://externals.io/message/107470#107437 · In reply to: #107433 > a middle ground about/with silliness? there is none, for people in their right mind; should people really find/force > themselves into conciliation about non-sense? I don't think so and mostly; I have no say about deprecating that; > but is that a priority? does it harm anyone? someone have died from backtick infection, it must be according to some? > and so on. Don't see where there is a heated topic; solely a reminder about reality and facts. > What would a happy medium be? backticks working 50% of the time? > This is like someone being pregnant, either you are or you are not there is > no half pregnant. Either backticks work like they have in shells for decades > or they don't work. What's the point of deprecating them without a plan to > remove them? A notice without future action is a bad idea, as it sets > standard that some deprecation messages will not be acted upon. Well, those are exactly the opposite of the types of responses I had hoped for. Responses that ignore the concerns of others. Responses that (implicitly?) insult the intelligence of others. And responses that can only see things from one myopic perspective. These responses highlight perfectly why discussions on this list are so contentious. -Mike --- ## #107438 — M. W. Moe — 2019-10-08T20:52:28+00:00 URL: https://externals.io/message/107470#107438 · In reply to: #107437 Hello, I answered you privately about this kind of false assumptions and projections. (I have an education) > > […] > right mind; should people really find/force > > […] > mostly; I have no say about deprecating that; > > […] > backtick infection, it must be according to some? > > […] > about reality and facts. > > > […] > is > > […] > decades > > […] > to > > […] > > Well, those are exactly the opposite of the types of responses I had hoped > for. > > Responses that ignore the concerns of others. Responses that (implicitly?) > insult the intelligence of others. And responses that can only see things > from one myopic perspective. > > These responses highlight perfectly why discussions on this list are so > contentious. > > -Mike --- ## #107439 — Mike Schinkel — 2019-10-08T21:13:53+00:00 URL: https://externals.io/message/107470#107439 · In reply to: #107436 > > My middle ground is a vote, regardless of outcome. If a vote is the middle ground then why the need to participate in any discussion? Also, how is a vote a middle ground? A vote ensures that one sides wins and the other side looses. IOW, a zero-sum game. Why does it not make better sense to actively look for ways to optimize outcomes so that the most people can win? For example... > This RFC is pretty simple, a deprecation + removal in a later patch, there's not much to compromise on the implementation. A compromise might be "NO agreement to remove in a later patch." Why does it not make sense to offer that up as a consolation to the one asking for deprecation? If they accepted and changed the RFC, then more people could get a "win." > If people think a deprecation should not be done or if it's not worth it, a vote is the way to show that opinion. > If there are enough reasons to not deprecate them, the voting process will show this and the RFC will be rejected. I have noticed on this list much discussion of the "minority vs. the majority." But that is a red-herring. There are a small number of people who have a vote (~200?) whereas there are over 5 million PHP developers and even more PHP stakeholders who have no vote. In other words, when internals@ votes unanimously on an RFC they still only represent ~0.004% of PHP stakeholders. Basically an aristocracy. So while a vote is a way to share an opinion, it is not representative of the opinions of those it may affect. It is a shame that the PHP voting process has no objective way to incorporate userland concerns except when some act as their proxy. Which is not the same as userland having explicit representatives with a vote. > PS. We need a CoC. 100% agree. -Mike P.S. I also think PHP needs an agreed statement of principles (Mission, Vision and Values.) With said statement RFCs could be evaluated to determine if they align with PHP's previously-agreed principles. Such a statement could be revised from time to time, but having one would resolve a lot of contentious debates before they happen. --- ## #107440 — M. W. Moe — 2019-10-08T21:25:08+00:00 URL: https://externals.io/message/107470#107440 · In reply to: #107439 Hello, what you write and advocate for can't be heard by a vast majority of people here; because they are just not North-American; somehow that's a very interesting trait; most of people despise `kind` moralism. > > […] > > If a vote is the middle ground then why the need to participate in any > discussion? > > Also, how is a vote a middle ground? A vote ensures that one sides wins > and the other side looses. IOW, a zero-sum game. > > Why does it not make better sense to actively look for ways to optimize > outcomes so that the most people can win? For example... > > > […] > there's not much to compromise on the implementation. > > A compromise might be "NO agreement to remove in a later patch." > > Why does it not make sense to offer that up as a consolation to the one > asking for deprecation? If they accepted and changed the RFC, then more > people could get a "win." > > > […] > it, a vote is the way to show that opinion. > > […] > will show this and the RFC will be rejected. > > I have noticed on this list much discussion of the "minority vs. the > majority." But that is a red-herring. There are a small number of people > who have a vote (~200?) whereas there are over 5 million PHP developers and > even more PHP stakeholders who have no vote. > > In other words, when internals@ votes unanimously on an RFC they still > only represent ~0.004% of PHP stakeholders. Basically an aristocracy. > > So while a vote is a way to share an opinion, it is not representative of > the opinions of those it may affect. It is a shame that the PHP voting > process has no objective way to incorporate userland concerns except when > some act as their proxy. Which is not the same as userland having explicit > representatives with a vote. > > > […] > > 100% agree. > > -Mike > > P.S. I also think PHP needs an agreed statement of principles (Mission, > Vision and Values.) With said statement RFCs could be evaluated to > determine if they align with PHP's previously-agreed principles. Such a > statement could be revised from time to time, but having one would resolve > a lot of contentious debates before they happen. --- ## #107441 — Walter Parker — 2019-10-08T21:26:29+00:00 URL: https://externals.io/message/107470#107441 · In reply to: #107440 > Hello, > > what you write and advocate for can't be heard by a vast majority of people > here; because they are just not North-American; somehow > that's a very interesting trait; most of people despise `kind` moralism. > > > > > > […] > and > > […] > explicit > > […] > resolve > > […] > The original proposal reads like: I don't understand it, I've talked to other that don't understand it. Not understand something makes learning the language harder, so we should get rid of the feature. How is this not Mark Twain's plan for the Improvement of Spelling in the English language? A Plan for the Improvement of Spelling in the English Language By Mark Twain For example, in Year 1 that useless letter “c” would be dropped to be replased either by “k” or “s”, and likewise “x” would no longer be part of the alphabet. The only kase in which “c” would be retained would be the “ch” formation, which will be dealt with later. Year 2 might reform “w” spelling, so that “which” and “one” would take the same konsonant, wile Year 3 might well abolish “y” replasing it with “i” and iear 4 might fiks the “g/j” anomali wonse and for all. Generally, then, the improvement would kontinue iear bai iear with iear 5 doing awai with useless double konsonants, and iears 6-12 or so modifaiing vowlz and the rimeiniing voist and unvoist konsonants. Bai iear 15 or sou, it wud fainali bi posibl tu meik ius ov thi ridandant letez “c”, “y” and “x”—bai now jast a memori in the maindz ov ould doderez —tu riplais “ch”, “sh”, and “th” rispektivili. Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld. Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis --- ## #107442 — Zeev Suraski — 2019-10-08T21:34:13+00:00 URL: https://externals.io/message/107470#107442 · In reply to: #107437 > > […] > right mind; should people really find/force > > […] > mostly; I have no say about deprecating that; > > […] > backtick infection, it must be according to some? > > […] > about reality and facts. > > > […] > is > > […] > decades > > […] > to > > […] > > Well, those are exactly the opposite of the types of responses I had hoped > for. > Mike, In a parallel universe, where this proposal has never been created and brought up for discussion - backticks would continue to work precisely as they did for twenty years, precisely with the advantages and disadvantages they had the day they were introduced, and this continue being the non-issue that it’s always been. Nobody would be thinking about it, opining about it and let alone quarreling about it. Unfortunately, we don’t live in that parallel universe, and suddenly this thing that bugged nobody for decades becomes a sudden priority for discussion. It’s also not as if we can ignore it either - we’ve seen how that went with short tags. So while I sympathize with the effort to find a compromise - encouraging more of these contentious proposals (by accommodating them at some level) is not the way. The real middle ground is to go for some form of opt-in solution. Whether it’s granular declares, strict mode, P++, editions - this is the only way to diffuse this contention - by rendering it irrelevant - precisely as it should be. Contrary to the perception many here appear to be under, there’s no feasibility question-mark over any of these options - they’re all doable, and even easy to implement. This solution would also not be some band aid until the next out of the blue proposal comes along - but a framework to thoroughly diffuse these types of contention once and for all. Zeev --- ## #107443 — Mike Schinkel — 2019-10-08T22:38:06+00:00 URL: https://externals.io/message/107470#107443 · In reply to: #107442 > > So while I sympathize with the effort to find a compromise - encouraging more of these contentious proposals (by accommodating them at some level) is not the way. Ok, but... > The real middle ground is to go for some form of opt-in solution. Whether it’s granular declares, strict mode, P++, editions - this is the only way to diffuse this contention - by rendering it irrelevant - precisely as it should be. Contrary to the perception many here appear to be under, there’s no feasibility question-mark over any of these options - they’re all doable, and even easy to implement. This solution would also not be some band aid until the next out of the blue proposal comes along - but a framework to thoroughly diffuse these types of contention once and for all. ...it seems you have identified at least one way to seek compromise. Why not move forward with this, in general? Said another way, why not discuss and debate BC breakage in abstract — and any other contention topics — and then establish a set of principles that the community can agree to use? This could be done in an RFC, and much like Mission, Vision and Values statements that organizations use to help them decide if they should pursue specific opportunities, a set of principles like these could help the internals@ have the debates once, in abstract, and then apply those principles to evaluate future RFCs? If course really cut down on ongoing contentious debate. I would create an RFC like that but AFAIK I have not developed enough clout here thus far so it would have to be from someone already well respected. -Mike P.S. You argument against compromises ironically soundsvery similar to the argument that leaving certain syntax in PHP encourages people to use it, and thus write "bad" code. Do you not see the similarities? --- ## #107451 — Zeev Suraski — 2019-10-09T07:50:27+00:00 URL: https://externals.io/message/107470#107451 · In reply to: #107443 > ...it seems you have identified at least one way to seek compromise. Why > not move forward with this, in general? > > I did - quite a while ago - and I see no reason not to, except that the pro-strict/pro-let’s-break-things camp either ignores that proposal entirely, or calls it a fork (it’s a fork in precisely the same way that PHP is a spoon). Note that I don’t really view it as a compromise, which is why I wrote my reply to you the way that I did. Instead, I see it as a complete win/win for both camps. It’s radically different from thoroughly entertaining each and every proposal with the inevitable contentious discussion that would ensue - in the context of changing PHP and both forcing people to change how they work as well as break existing code - and come up with some technical middle ground between “we shouldn’t touch it” and “we must kill it”. > Said another way, why not discuss and debate BC breakage in abstract — and > any other contention topics — and then establish a set of principles that > the community can agree to use? > > I don’t know. The last time I tried to do it, someone pulled an overnight pseudo-RFC to stop the discussion, radically mischaracterizing the proposal, abusing a vote to shutdown discussion, and creating the fundamentally wrong impression that this is about the technical feasibility of achieving this - and not about whether we want to go down that route or not. I’m all for discussing it (the principle, not necessarily in the P++ form). I would create an RFC like that but AFAIK I have not developed enough clout > here thus far so it would have to be from someone already well respected. > > As I wrote a couple of weeks back, before we agree on the principle - that these contentious, breaking-for-no-new-reason proposals can’t be forced on everyone but we need to make it opt-in, I don’t think formalizing it into an RFC would help. I could be wrong, but I think we’re currently lacking in good will on the other camp, which appears to feel a lot more comfortable to just go on producing contentious proposals day in and day out, and live with whatever sticks. P.S. You argument against compromises ironically soundsvery similar to the > argument that leaving certain syntax in PHP encourages people to use it, > and thus write "bad" code. Do you not see the similarities? > In a nutshell, no, not really. Feel free to try to convince me otherwise off list - I’ll report back if convinced :) Zeev --- ## #107450 — Nikita Popov — 2019-10-09T08:11:17+00:00 URL: https://externals.io/message/107470#107450 > Hi Internals, > > I put forward the following RFC "Deprecate Backtick Operator (V2)" for > discussion. > > https://wiki.php.net/rfc/deprecate-backtickTrying to drag every single > discussion to the meta level is exactly what is causing these unnecessary, > time wasting discussions. This is a small proposal with a limited number of > arguments for and against, and it's unfortunate that your participation in > the discussion has once again -operator-v2 > > > I believe it is at least worth a discussion as to the pros and cons of > deprecating this functionality, especially in light of the existence of > better described and more well-known functions exhibiting identical > behaviour. > > This RFC only covers the issuing a deprecation notice, and its complete > removal would be contained within a separate RFC. > My 2c on this proposal: I think the primary motivation for me here would be the security aspect... On one hand, the existence of the backtick operator in PHP borders on criminal negligence, because it exposes the **single most dangerous** operation in the entire language in a way that looks innocuous, is easy to confuse with a string literal and that the majority of PHP programmers are not aware of. This looks like a great way to slip a nice RCE vulnerability past code review ;) On the other hand, I have seen no evidence of backticks actually causing security issues in practice. I guess it doesn't because it's not a feature you'll end up using accidentally, and it does not seem like attempts at inserting backdoors into open-source projects by 3rd party contributors are common. Is anyone aware of specific security incidents that can be attributed to the backtick operator? Meta: Wow, do we really need to drag every single discussion that contains the word "deprecation" up to the meta level? This is a really simple proposal, with a very limited set of arguments for and against. I hope we can consider the proposal on its merits (or non-merits) rather than turning it into some kind of proxy war. Yes, "it breaks backwards compatibility for questionable benefit" is an argument against this proposal, it is even a *very good* argument against it, but it's also no mandate to shut down the discussion entirely. Nikita --- ## #107452 — Lynn — 2019-10-09T08:25:08+00:00 URL: https://externals.io/message/107470#107452 · In reply to: #107439 Hi, > If a vote is the middle ground then why the need to participate in any > discussion? > > Also, how is a vote a middle ground? A vote ensures that one sides wins > and the other side looses. IOW, a zero-sum game. > > Why does it not make better sense to actively look for ways to optimize > outcomes so that the most people can win? For example... > > There is no middle ground in an RFC that proposes the deprecation at this level of specifics. You either deprecate it, or you don't. The only middle ground you can reach, is that you give it a vote to see if it should indeed be deprecated. Perhaps I'm looking at it from a wrong perspective, it looks very binary to me (see next answer for why). > A compromise might be *"NO agreement to remove in a later patch."* > > Why does it not make sense to offer that up as a consolation to the one > asking for deprecation? If they accepted and changed the RFC, then more > people could get a "win." > > The idea behind a deprecation is that you are discouraging its use and plan to remove it at a later stage. To me it makes no sense to deprecate something but never remove it, might as well not deprecate it at that point. Either we accept it's in the language and keep it, or we remove it at some point, which ideally gets a deprecation first to ease migrations. I have noticed on this list much discussion of the "minority vs. the > majority." But that is a red-herring. There are a small number of people > who have a vote (~200?) whereas there are over 5 million PHP developers and > even more PHP stakeholders who have no vote. > > In other words, when internals@ votes unanimously on an RFC they still > only represent ~0.004% of PHP stakeholders. Basically an aristocracy. > > So while a vote is a way to share an opinion, it is not representative of > the opinions of those it may affect. It is a shame that the PHP voting > process has no objective way to incorporate userland concerns except when > some act as their proxy. Which is not the same as userland having explicit > representatives with a vote. > > I agree. There are a lot of unhappy user-land voices about a lot of decisions made here. Sadly I don't see a way to give everyone a voice in this. Regards, Lynn van der Berg --- ## #107455 — Larry Garfield — 2019-10-09T16:58:26+00:00 URL: https://externals.io/message/107470#107455 · In reply to: #107451 > As I wrote a couple of weeks back, before we agree on the principle - that > these contentious, breaking-for-no-new-reason proposals can’t be forced on > everyone but we need to make it opt-in, I don’t think formalizing it into > an RFC would help. I could be wrong, but I think we’re currently lacking > in good will on the other camp, which appears to feel a lot more > comfortable to just go on producing contentious proposals day in and day > out, and live with whatever sticks. Tangent: I think it's a mischaracterization to divide opinions about PHP's future into "two camps", one of which wants to defend BC and never change anything and make the language as loosy-goosey as possible, and one that doesn't care about BC and wants to turn it into Haskell. Those are hyperbolic and incorrect descriptions of where I see people standing, and creating that "two warring camps" impression only makes the question about how PHP should evolve harder to resolve. There are several distinct axes of philosophical debate, and they do not necessarily correlate at all. 1) More BC protection vs less. 2) More opt-in "syntactic error checking" (eg, typing) vs less. 3) Fail hard on error cases vs "assume what was probably intended". 4) More "simplify common tasks" sugar vs less. 5) "performance reigns supreme" vs "spending performance to get usability is a good tradeoff". And probably many others I can't think of right now. Those various axes do not all correlate, and I suspect all 32 combinations of answers to those questions are represented by someone on this list, even before getting to the fact that they're all scales, not binaries, and some overlap in interesting ways (eg, failing hard is in some cases a BC break, others not). Zeev, you're very strongly and vocally on the "more BC protection" side. That's fine; I agree with you, by and large. But lumping "pfft, BC" in with "moar types" and "fail hard" and "moar sugar" and then dismissing them as "the other camp" does not advance the cause of BC protection, nor does it advance the cause of Internals not being a running gag of dysfunction, nor does it advance the cause of making PHP a better language, for any definition of better. As long as "anyone is allowed to propose an RFC", we *will* get RFCs that go against the informal consensus. Over time, that informal consensus will thus shift. That is an inevitable and unavoidable result of PHP's loosey-goosey structure. If you want to really protect BC, the way to do that is to actually put guidelines in writing that people have to read before proposing an RFC, and that we can point to when people ignore them anyway. But "that's how we've always done it, no it's not written down but we really have" is an approach doomed to not only fail, but to maximize the amount of strife as it fails. Let's please not do that. And developing such guidelines absolutely positively cannot happen on a public asynchronous mailing list. I've been through such processes enough times to know that is the worst possible way to do it. --Larry Garfield --- ## #107458 — Mike Schinkel — 2019-10-09T18:38:47+00:00 URL: https://externals.io/message/107470#107458 · In reply to: #107455 > > And developing such guidelines absolutely positively cannot happen on a public asynchronous mailing list. I've been through such processes enough times to know that is the worst possible way to do it. When I first saw this email I thought you were proposing IRL "camp" ala a symposium/convention/assembly where "delegates" from the internals@ list were to get together face-to-face and collaborate on moving PHP forward. I think people might be a lot more willing to work together for mutual benefit if they were working in the same room rather than on their own in front of their keyboards. Maybe that would be a way to move forward with some of the log jams here? Basically an initial meeting and then a plan to do it periodically in the future (annual or bi-annual?) -Mike --- ## #107461 — Stanislav Malyshev — 2019-10-10T03:26:31+00:00 URL: https://externals.io/message/107470#107461 · In reply to: #107458 Hi! > Maybe that would be a way to move forward with some of the log jams here? I'm not sure where's the log jam here? An RFC proposing largely pointless deprecation not being met with overall enthusiasm is not a "logjam". It's a logjam only if somehow we were to imagine more BC breaks, more deprecations and more removal of functionality is somehow vitally necessary for PHP - which decades of thriving without all that amply prove to be false. I don't see what's wrong with just "do not break BC unless you absolutely can't avoid it" and why we need some grand World Council to arrive to this simple guideline that has been understood as obvious for years and has been also accepted by many other software projects? How comes now we have to spend so much time at affirming the obvious? -- Stas Malyshev smalyshev@gmail.com --- ## #107462 — Stanislav Malyshev — 2019-10-10T03:35:38+00:00 URL: https://externals.io/message/107470#107462 · In reply to: #107450 Hi! > it into some kind of proxy war. Yes, "it breaks backwards compatibility for > questionable benefit" is an argument against this proposal, it is even a > *very good* argument against it, but it's also no mandate to shut down the > discussion entirely. Well, anyone is free to continue the discussion forever and ever (there's no real way of "shutting down" it), but if there a *very good* argument against it, then the point of continuing would be.... ? -- Stas Malyshev smalyshev@gmail.com --- Next page: https://externals.io/message/107470.md?page=2