Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

  107392
October 7, 2019 07:50 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Oct 4, 2019 at 5:45 PM Mark Randall <marandall@php.net> wrote:

> 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
October 8, 2019 03:31 theodorejb@outlook.com (Theodore Brown)
On Mon, Oct 7, 2019 at 2:50 AM Nikita Popov ppv@gmail.com> wrote:

> On Fri, Oct 4, 2019 at 5:45 PM Mark Randall <marandall@php.net> wrote: > > > 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 :)
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
October 8, 2019 07:49 zeev@php.net (Zeev Suraski)
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.

On Tue, 8 Oct 2019 at 5:32 Theodore Brown <theodorejb@outlook.com> wrote:

> > 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
October 8, 2019 08:46 lester@lsces.uk (Lester Caine)
On 08/10/2019 04:31, Theodore Brown wrote:
> 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
October 8, 2019 09:09 benjamin.morel@gmail.com (Benjamin Morel)
> 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 On Tue, 8 Oct 2019 at 10:47, Lester Caine <lester@lsces.uk> wrote:
> On 08/10/2019 04:31, Theodore Brown wrote: > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107415
October 8, 2019 11:02 r@roze.lv ("Reinis Rozitis")
> -----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
October 8, 2019 18:19 smalyshev@gmail.com (Stanislav Malyshev)
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
October 8, 2019 20:12 mike@newclarity.net (Mike Schinkel)
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
October 8, 2019 20:22 mo.mu.wss@gmail.com ("M. W. Moe")
@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.

On Tue, Oct 8, 2019 at 1:12 PM Mike Schinkel <mike@newclarity.net> wrote:

> 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
  107435
October 8, 2019 20:26 walterp@gmail.com (Walter Parker)
On Tue, Oct 8, 2019 at 1:23 PM M. W. Moe wss@gmail.com> wrote:

> @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. > > On Tue, Oct 8, 2019 at 1:12 PM Mike Schinkel <mike@newclarity.net> wrote: > > > 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 >
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
  107437
October 8, 2019 20:38 mike@newclarity.net (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.
> 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
October 8, 2019 20:52 mo.mu.wss@gmail.com ("M. W. Moe")
Hello,

I answered you privately about this kind of false assumptions and
projections. (I have an education)

On Tue, Oct 8, 2019 at 1:38 PM Mike Schinkel <mike@newclarity.net> wrote:

> > 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
  107442
October 8, 2019 21:34 zeev@php.net (Zeev Suraski)
On Tue, 8 Oct 2019 at 22:38 Mike Schinkel <mike@newclarity.net> wrote:

> > 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. >
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
October 8, 2019 22:38 mike@newclarity.net (Mike Schinkel)
> On Oct 8, 2019, at 5:34 PM, Zeev Suraski <zeev@php.net> wrote: > 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
October 9, 2019 07:50 zeev@php.net (Zeev Suraski)
On Wed, 9 Oct 2019 at 0:38 Mike Schinkel <mike@newclarity.net> wrote:

> ...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
>
  107455
October 9, 2019 16:58 larry@garfieldtech.com ("Larry Garfield")
On Wed, Oct 9, 2019, at 2:50 AM, Zeev Suraski wrote:

> 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
October 9, 2019 18:38 mike@newclarity.net (Mike Schinkel)
> On Oct 9, 2019, at 12:58 PM, Larry Garfield <larry@garfieldtech.com> wrote: > 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
October 10, 2019 03:26 smalyshev@gmail.com (Stanislav Malyshev)
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
  107463
October 10, 2019 04:11 mike@newclarity.net (Mike Schinkel)
> I'm not sure where's the log jam here?
The issue is not this specific RFC. As I wrote earlier, there appear to be heated and non-stop debates over (at least) BC, and possibly other areas. People dig in on a position and then won't consider any other options that might be available.
> 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.
Let me restate then, because what was important was not that the word I used matched internals@ circumstances exactly, but the fact that there is an issue with how the process currently works, as many other people have noted already. We can call it something other than a logjam if it is important to you that the word matches. What about dysfunction instead?
> I don't see what's wrong with just "do not break BC unless you > absolutely can't avoid it"... How comes now we have to spend > so much time at affirming the obvious?
Frankly I would agree with that, if it were not for a large number of people who are actively promoting changes to PHP that would break BC. So clearly the current composition of this list includes people who see something wrong with the approach you see no reason to question. Note I am not endorsing their opinion but I am recognizing they have this opinion and they are actively trying to change PHP. So we can embrace insanity — as Einstein would say — and fight never-ending battles on the list, or we can find ways to accommodate everyones needs and wants, assuming everyone else is willing to find way to accommodate the needs and wants of people that disagree with them. Looking in from the outside, few people who send emails to this list appear to be interested in finding common ground. But maybe if we help everyone recognize that nobody wins — including themselves — when a group of people divide up and stake out intransigent and diametrically-opposed positions then the list can be a lot more productive. No single person owns PHP so it is rather ungenerous to adopt a view that PHP should conform to any one individual view of the perfect programming language. So what if instead we collectively ask ourselves the question "What can I do to meet the other people half way — in ways that won't really cost me all that much — rather than to maintain an unrelentingly rigid posture about the needs and wants of others?" -Mike
  107471
October 10, 2019 17:03 chasepeeler@gmail.com (Chase Peeler)
On Thu, Oct 10, 2019 at 12:11 AM Mike Schinkel <mike@newclarity.net> wrote:

> > I'm not sure where's the log jam here? > > The issue is not this specific RFC. > > As I wrote earlier, there appear to be heated and non-stop debates over > (at least) BC, and possibly other areas. People dig in on a position and > then won't consider any other options that might be available. > > > 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. > > Let me restate then, because what was important was not that the word I > used matched internals@ circumstances exactly, but the fact that there is > an issue with how the process currently works, as many other people have > noted already. > > We can call it something other than a logjam if it is important to you > that the word matches. What about dysfunction instead? > > > I don't see what's wrong with just "do not break BC unless you > > absolutely can't avoid it"... How comes now we have to spend > > so much time at affirming the obvious? > > Frankly I would agree with that, if it were not for a large number of > people who are actively promoting changes to PHP that would break BC. So > clearly the current composition of this list includes people who see > something wrong with the approach you see no reason to question. > > Note I am not endorsing their opinion but I am recognizing they have this > opinion and they are actively trying to change PHP. So we can embrace > insanity — as Einstein would say — and fight never-ending battles on the > list, or we can find ways to accommodate everyones needs and wants, > assuming everyone else is willing to find way to accommodate the needs and > wants of people that disagree with them. > > Looking in from the outside, few people who send emails to this list > appear to be interested in finding common ground. But maybe if we help > everyone recognize that nobody wins — including themselves — when a group > of people divide up and stake out intransigent and diametrically-opposed > positions then the list can be a lot more productive. > > No single person owns PHP so it is rather ungenerous to adopt a view that > PHP should conform to any one individual view of the perfect programming > language. So what if instead we collectively ask ourselves the question > "What can I do to meet the other people half way — in ways that won't > really cost me all that much — rather than to maintain an unrelentingly > rigid posture about the needs and wants of others?" > > -Mike > > Mike - I have no issue with compromise when it makes sense. Sometimes,
though, it doesn't. I'll paraphrase an example given by Jonah Goldberg. One side wants to build a 100 yard bridge to an island. The other side doesn't think we need to build the bridge because we don't need to go to the island. What's the compromise? Building a 50 yard bridge? The fact is, when there is a compromise that makes sense, people usually suggest it. One example being Zeev's proposal on the RFC to raise the error levels of undefined variables to making it opt-in. Zeev's stance on the issue was that we shouldn't do anything that was mentioned in the RFC, but, he felt that a compromise would be to at least make those changes opt-in. That proposal was rejected by pretty much everyone. That's probably why it wasn't proposed this time, either. As for this particular RFC, I think it's a pretty binary decision. Deprecate them or don't. As long as I've been involved with PHP, nothing is ever deprecated unless the eventual goal is to remove it. I could be wrong, and welcome examples where we've deprecated something where the end goal wasn't removal. Assuming I'm correct though, that provides a pretty strong reason for why we wouldn't start doing it now. -- Chase Peeler chasepeeler@gmail.com
  107473
October 10, 2019 17:14 bishop@php.net (Bishop Bettini)
On Thu, Oct 10, 2019, 13:03 Chase Peeler <chasepeeler@gmail.com> wrote:

> On Thu, Oct 10, 2019 at 12:11 AM Mike Schinkel <mike@newclarity.net> > wrote: > > > > I'm not sure where's the log jam here? > > > > The issue is not this specific RFC. > > > > As I wrote earlier, there appear to be heated and non-stop debates over > > (at least) BC, and possibly other areas. People dig in on a position and > > then won't consider any other options that might be available. > > > > > 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. > > > > Let me restate then, because what was important was not that the word I > > used matched internals@ circumstances exactly, but the fact that there > is > > an issue with how the process currently works, as many other people have > > noted already. > > > > We can call it something other than a logjam if it is important to you > > that the word matches. What about dysfunction instead? > > > > > I don't see what's wrong with just "do not break BC unless you > > > absolutely can't avoid it"... How comes now we have to spend > > > so much time at affirming the obvious? > > > > Frankly I would agree with that, if it were not for a large number of > > people who are actively promoting changes to PHP that would break BC. So > > clearly the current composition of this list includes people who see > > something wrong with the approach you see no reason to question. > > > > Note I am not endorsing their opinion but I am recognizing they have this > > opinion and they are actively trying to change PHP. So we can embrace > > insanity — as Einstein would say — and fight never-ending battles on the > > list, or we can find ways to accommodate everyones needs and wants, > > assuming everyone else is willing to find way to accommodate the needs > and > > wants of people that disagree with them. > > > > Looking in from the outside, few people who send emails to this list > > appear to be interested in finding common ground. But maybe if we help > > everyone recognize that nobody wins — including themselves — when a group > > of people divide up and stake out intransigent and diametrically-opposed > > positions then the list can be a lot more productive. > > > > No single person owns PHP so it is rather ungenerous to adopt a view that > > PHP should conform to any one individual view of the perfect programming > > language. So what if instead we collectively ask ourselves the question > > "What can I do to meet the other people half way — in ways that won't > > really cost me all that much — rather than to maintain an unrelentingly > > rigid posture about the needs and wants of others?" > > > > -Mike > > > > > Mike - I have no issue with compromise when it makes sense. Sometimes, > though, it doesn't. I'll paraphrase an example given by Jonah Goldberg. One > side wants to build a 100 yard bridge to an island. The other side doesn't > think we need to build the bridge because we don't need to go to the > island. What's the compromise? Building a 50 yard bridge? >
No. The compromise is funding a ferry system. Or laying Internet between them. Or a passenger pigeon mail route. Sometimes compromise requires deep discussion about the motivations for each side and coming to a lateral, mutually acceptable, solution. But we'd rather not discuss motivations and just bicker about the surface results. I.e., argue the X, rather than the Y, of these little XY problems we're solving.
> The fact is, when there is a compromise that makes sense, people usually > suggest it. One example being Zeev's proposal on the RFC to raise the error > levels of undefined variables to making it opt-in. Zeev's stance on the > issue was that we shouldn't do anything that was mentioned in the RFC, but, > he felt that a compromise would be to at least make those changes opt-in. > That proposal was rejected by pretty much everyone. That's probably why it > wasn't proposed this time, either. > > As for this particular RFC, I think it's a pretty binary decision. > Deprecate them or don't. As long as I've been involved with PHP, nothing is > ever deprecated unless the eventual goal is to remove it. I could be wrong, > and welcome examples where we've deprecated something where the end goal > wasn't removal. Assuming I'm correct though, that provides a pretty strong > reason for why we wouldn't start doing it now. >
Short tags are deprecated, per the manual. They are not planned to be removed and, per the vote discussions and margins, probably won't ever go.
>
  107474
October 10, 2019 17:30 walterp@gmail.com (Walter Parker)
> > > No. The compromise is funding a ferry system. Or laying Internet between > them. Or a passenger pigeon mail route. > > Sometimes compromise requires deep discussion about the motivations for > each side and coming to a lateral, mutually acceptable, solution. > > But we'd rather not discuss motivations and just bicker about the surface > results. I.e., argue the X, rather than the Y, of these little XY problems > we're solving. > > > Build a ferry system is alternative to building bridge. I can see that as a
compromise, I can also see that as a separate project created to serve demand after the the bridge project is rejected. Where a ferry system is started because there is still demand for transit, just not enough demand to pay for a bridge. With respect to the backtick proposal, what is the "ferry" project? Do we have to come up with one before we can cancel the "bridge" project or can we cancel the "bridge" project on its own merits and then discuss a future project that solves the actual underlying problem? "Ferry" projects might be: more/better training on PHP, better documentation so that the backtick is no longer an "obscure" feature to those that don't have a shell/Unix/Perl background, tooling to warn people when they misuse this feature. Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
  107475
October 10, 2019 17:36 chasepeeler@gmail.com (Chase Peeler)
On Thu, Oct 10, 2019 at 1:30 PM Walter Parker <walterp@gmail.com> wrote:

> > > > > > No. The compromise is funding a ferry system. Or laying Internet between > > them. Or a passenger pigeon mail route. > > > > Sometimes compromise requires deep discussion about the motivations for > > each side and coming to a lateral, mutually acceptable, solution. > > > > But we'd rather not discuss motivations and just bicker about the surface > > results. I.e., argue the X, rather than the Y, of these little XY > problems > > we're solving. > > > > > > > Build a ferry system is alternative to building bridge. I can see that as a > compromise, I can also see that as a separate project created to serve > demand after the the bridge project is rejected. Where a ferry system is > started because there is still demand for transit, just not enough demand > to pay for a bridge. > > With respect to the backtick proposal, what is the "ferry" project? Do we > have to come up with one before we can cancel the "bridge" project or can > we cancel the "bridge" project on its own merits and then discuss a future > project that solves the actual underlying problem? > > "Ferry" projects might be: more/better training on PHP, better > documentation so that the backtick is no longer an "obscure" feature to > those that don't have a shell/Unix/Perl background, tooling to warn people > when they misuse this feature. > > > To the side that says "There is absolutely no reason we need to go to, or
communicate with, the island in the first place," a ferry project isn't a compromise. The position of the "anti-bridge" builders isn't because they are against building bridges - it's because they are against spending resources on attempts to get to the island in the first place. The other side might have valid arguments on why we need to get to the island, but, just proposing different ways to get there isn't compromising with the side that doesn't want to go there.
> Walter > > -- > The greatest dangers to liberty lurk in insidious encroachment by men of > zeal, well-meaning but without understanding. -- Justice Louis D. > Brandeis >
-- Chase Peeler chasepeeler@gmail.com
  107480
October 10, 2019 19:59 walterp@gmail.com (Walter Parker)
On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler <chasepeeler@gmail.com> wrote:

> > > On Thu, Oct 10, 2019 at 1:30 PM Walter Parker <walterp@gmail.com> wrote: > >> > >> > >> > No. The compromise is funding a ferry system. Or laying Internet between >> > them. Or a passenger pigeon mail route. >> > >> > Sometimes compromise requires deep discussion about the motivations for >> > each side and coming to a lateral, mutually acceptable, solution. >> > >> > But we'd rather not discuss motivations and just bicker about the >> surface >> > results. I.e., argue the X, rather than the Y, of these little XY >> problems >> > we're solving. >> > >> > >> > >> Build a ferry system is alternative to building bridge. I can see that as >> a >> compromise, I can also see that as a separate project created to serve >> demand after the the bridge project is rejected. Where a ferry system is >> started because there is still demand for transit, just not enough demand >> to pay for a bridge. >> >> With respect to the backtick proposal, what is the "ferry" project? Do we >> have to come up with one before we can cancel the "bridge" project or can >> we cancel the "bridge" project on its own merits and then discuss a future >> project that solves the actual underlying problem? >> >> "Ferry" projects might be: more/better training on PHP, better >> documentation so that the backtick is no longer an "obscure" feature to >> those that don't have a shell/Unix/Perl background, tooling to warn people >> when they misuse this feature. >> >> >> > To the side that says "There is absolutely no reason we need to go to, or > communicate with, the island in the first place," a ferry project isn't a > compromise. The position of the "anti-bridge" builders isn't because they > are against building bridges - it's because they are against spending > resources on attempts to get to the island in the first place. The other > side might have valid arguments on why we need to get to the island, but, > just proposing different ways to get there isn't compromising with the side > that doesn't want to go there. >
I think you may have just created a strawman for the anti-bridge position. There are famous anti-bridge cases, like the Bridge to Nowhere in Alaska (if you don't remember, there was an island in Alaska that had 50 people and Senator Stevens wanted to replace the existing ferry system with a $398 million bridge). People complained about the bridge not because they wanted the islanders to to isolated, but because it was poor use of money when there where bigger and more urgent problems. To bring this back to PHP, is the backtick really a urgent problem of enough magnitude that it justifies the cost of a BC break in unknown amount of PHP code that has been functional for years. If this proposal passes (and the follow up to remove it which I'm certain will be proposed), then this is one that leaves people on the island as they will either be stuck on an old version of PHP or have to pay to update the code. This pushes the costs on them to solve a an existing issue that 20 years after it was created and is now an issue because a new generation of coders, unaware of history, find the existing syntax not to there taste/a poor design. Why are we giving priority to people that haven't taken the time to educate themselves over people that did and used programming style that used to common?
> > >> Walter >> >> -- >> The greatest dangers to liberty lurk in insidious encroachment by men of >> zeal, well-meaning but without understanding. -- Justice Louis D. >> Brandeis >> > > > -- > Chase Peeler > chasepeeler@gmail.com >
-- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
  107482
October 10, 2019 20:27 marandall@php.net (Mark Randall)
On 10/10/2019 20:59, Walter Parker wrote:
> They will either be stuck on an old version of PHP or have to pay to update the code.
If you're getting stuck on a island after being given 4 or 5 years warning that the bridge to it will be closed, after being pointed to the ferry, given free tickets to that ferry, and being told it will continue to run long after, that's your own fault.
> This pushes the > costs on them to solve a an existing issue that 20 years after it was > created and is now an issue because a new generation of coders, unaware of > history, find the existing syntax not to there taste/a poor design.
History does not mean it was a good idea at the time, and even if it was, that doesn't mean it's a good idea now. Times move on. Your argument could easily be reversed... An old generation of coders, stuck in their ways, inflexible, preferring what they know rather than changing with the times for the greater good.
> Why are > we giving priority to people that haven't taken the time to educate > themselves over people that did and used programming style that used to > common?
We're assuming that in a general purpose programming languages, most programmers expect a function call to look like a function call, and not a string. We're assuming that people don't just go from never having touched PHP, to expert level, knowing all its quirks and secrets, within a few hours. We're assuming that there's a heck of a lot more to stewardship of the language than backwards compatibility. So let's look at it from the perspective of what we can do... We can either a) Find a way to reach out to every PHP programmer in the world and let them know that there's these special operators that look like a string, but actually aren't, and they do something that can be really dangerous, and they'll probably never see it but god help them if it's there and they miss it. or b) We add one line of code and warn people that we're eventually going to remove a rarely used and poorly understood syntax, and people should at some point in the next 4 or 5 migrate to the much more obvious shell_exec. By writing the RFC, it's pretty obvious which one I think is the best and most realistic course of action. Mark Randall
  107487
October 11, 2019 05:20 php-lists@koalephant.com (Stephen Reay)
> On 11 Oct 2019, at 02:59, Walter Parker <walterp@gmail.com> wrote: > > On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler <chasepeeler@gmail.com> wrote: > >> >> >> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker <walterp@gmail.com> wrote: >> >>>> >>>> >>>> No. The compromise is funding a ferry system. Or laying Internet between >>>> them. Or a passenger pigeon mail route. >>>> >>>> Sometimes compromise requires deep discussion about the motivations for >>>> each side and coming to a lateral, mutually acceptable, solution. >>>> >>>> But we'd rather not discuss motivations and just bicker about the >>> surface >>>> results. I.e., argue the X, rather than the Y, of these little XY >>> problems >>>> we're solving. >>>> >>>> >>>> >>> Build a ferry system is alternative to building bridge. I can see that as >>> a >>> compromise, I can also see that as a separate project created to serve >>> demand after the the bridge project is rejected. Where a ferry system is >>> started because there is still demand for transit, just not enough demand >>> to pay for a bridge. >>> >>> With respect to the backtick proposal, what is the "ferry" project? Do we >>> have to come up with one before we can cancel the "bridge" project or can >>> we cancel the "bridge" project on its own merits and then discuss a future >>> project that solves the actual underlying problem? >>> >>> "Ferry" projects might be: more/better training on PHP, better >>> documentation so that the backtick is no longer an "obscure" feature to >>> those that don't have a shell/Unix/Perl background, tooling to warn people >>> when they misuse this feature. >>> >>> >>> >> To the side that says "There is absolutely no reason we need to go to, or >> communicate with, the island in the first place," a ferry project isn't a >> compromise. The position of the "anti-bridge" builders isn't because they >> are against building bridges - it's because they are against spending >> resources on attempts to get to the island in the first place. The other >> side might have valid arguments on why we need to get to the island, but, >> just proposing different ways to get there isn't compromising with the side >> that doesn't want to go there. >> > > I think you may have just created a strawman for the anti-bridge position. > There are famous anti-bridge cases, like the Bridge to Nowhere in Alaska > (if you don't remember, there was an island in Alaska that had 50 people > and Senator Stevens wanted to replace the existing ferry system with a $398 > million bridge). People complained about the bridge not because they wanted > the islanders to to isolated, but because it was poor use of money when > there where bigger and more urgent problems. > > To bring this back to PHP, is the backtick really a urgent problem of > enough magnitude that it justifies the cost of a BC break in unknown amount > of PHP code that has been functional for years. If this proposal passes > (and the follow up to remove it which I'm certain will be proposed), then > this is one that leaves people on the island as they will either be stuck > on an old version of PHP or have to pay to update the code. This pushes the > costs on them to solve a an existing issue that 20 years after it was > created and is now an issue because a new generation of coders, unaware of > history, find the existing syntax not to there taste/a poor design. Why are > we giving priority to people that haven't taken the time to educate > themselves over people that did and used programming style that used to > common? > > >> >> >>> Walter >>> >>> -- >>> The greatest dangers to liberty lurk in insidious encroachment by men of >>> zeal, well-meaning but without understanding. -- Justice Louis D. >>> Brandeis >>> >> >> >> -- >> Chase Peeler >> chasepeeler@gmail.com >> > > > -- > The greatest dangers to liberty lurk in insidious encroachment by men of > zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
(Sorry, wrong account previously, so didn’t sent to the list) Hi Walter, The RFC at the centre of this ridiculous string of analogies is about one thing: deprecate (i.e. show a deprecation message) about the backtick operator. The RFC specifically doesn’t lay out a timeline for actual removal, it doesn’t even hint at “well it’ll just be automatically removed”. So this RFC breaks *nothing*. Yes, it does lead to the situation where it’s likely that a followup RFC will propose removing the (then) deprecated feature - perhaps 9.0, perhaps it’ll be discussed pre-9.0, and held off until 10.0? But any such change will then require *another* vote, with another round of discussions and no doubt ridiculous analogies. And at that time, after several years of warnings about deprecation, Nikita or someone else will likely pop up with some analysis of projects to show usage *at the time*. If the only reason to keep a dangerous operator is “well a small subset of people use it”, marking it as *deprecated* is how you signal to those people that the feature will likely be removed in a future version. The argument about “shell style scripts” that are on a server which constantly gets updated to the newest release but never gets any maintenance to the scripts is a ridiculous fantasy. There is zero chance someone is dist-upgrading from one release to the next through enough versions that they get to one where the distro-provided php is such that backticks are actually removed, and yet the only thing that breaks is the backticks. Cheers Stephen
  107476
October 10, 2019 18:04 marandall@php.net (Mark Randall)
On 10/10/2019 18:30, Walter Parker wrote:
> "Ferry" projects might be: more/better training on PHP, better > documentation so that the backtick is no longer an "obscure" feature to > those that don't have a shell/Unix/Perl background, tooling to warn people > when they misuse this feature.
Unfortunately most of those are out of our hands. While it would certainly be great if we could better educate everyone, such things are beyond the power of internals to do, and while we could improve the documentation, we're not in a position to tell everyone that new information is there, and even still, that wouldn't change that it's too easy to miss for the power it possesses. While a warning would be something, PHP's warnings don't actually prevent anything. By the time you see them, the problem has usually already occurred. That leaves us with the choice that's within our power, deprecation and eventual removal of backticks in favour of something that's much more obvious in its intent and much less easy to miss. Mark Randall
  107436
October 8, 2019 20:29 kjarli@gmail.com (Lynn)
On Tue, Oct 8, 2019 at 10:12 PM Mike Schinkel <mike@newclarity.net> wrote:

> 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.
  107439
October 8, 2019 21:13 mike@newclarity.net (Mike Schinkel)
> On Oct 8, 2019, at 4:29 PM, Lynn <kjarli@gmail.com> wrote: > 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
October 8, 2019 21:25 mo.mu.wss@gmail.com ("M. W. Moe")
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.


On Tue, Oct 8, 2019 at 2:14 PM Mike Schinkel <mike@newclarity.net> wrote:

> > On Oct 8, 2019, at 4:29 PM, Lynn <kjarli@gmail.com> wrote: > > 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. > > >
  107441
October 8, 2019 21:26 walterp@gmail.com (Walter Parker)
On Tue, Oct 8, 2019 at 2:25 PM M. W. Moe wss@gmail.com> wrote:

> 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. > > > On Tue, Oct 8, 2019 at 2:14 PM Mike Schinkel <mike@newclarity.net> wrote: > > > > On Oct 8, 2019, at 4:29 PM, Lynn <kjarli@gmail.com> wrote: > > > 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. > > > > > > >
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
  107452
October 9, 2019 08:25 kjarli@gmail.com (Lynn)
Hi,

On Tue, Oct 8, 2019 at 11:13 PM Mike Schinkel <mike@newclarity.net> wrote:

> 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