Evolving PHP

  107079
September 13, 2019 14:10 rasmus@lerdorf.com (Rasmus Lerdorf)
Lots of drama on internals lately. Not that different from 15-20 years ago.
A couple of things to keep in mind for everyone.

It is not that hard to write a tool that perfectly fits your own needs and
people who are very similar to you in terms of skillset, background and
overall experience. What PHP has always strived to do is to be much broader
than that. Writing a tool that is very approachable to beginners that can
still scale to some of the largest sites in the world is a much harder and
more interesting problem and requires some compromises on both ends.

The people writing the code get to call the shots, for better or worse. In
the beginning I called all the shots. As more people started to contribute
it took me a while to let go and accept contributions I didn't agree with.
We wouldn't be here today if I hadn't done that.

-Rasmus
  107081
September 13, 2019 14:57 cschneid@cschneid.com (Christian Schneider)
Am 13.09.2019 um 16:10 schrieb Rasmus Lerdorf <rasmus@lerdorf.com>:
> The people writing the code get to call the shots, for better or worse.
There's some caveats with this: 1) What does "write the code" mean? What is the threshold when I can take over a project? 2) With a bigger user-base there is also bigger responsibility. So things are a bit different than 15 years ago. 3) PHP used to be more like Linus' "WE DO NOT BREAK USERSPACE!" ("...without *major* benefit" in the PHP case) and I wonder when we abandoned this maxim. - Chris
  107082
September 13, 2019 15:02 oludonsexy@gmail.com (Olumide Samson)
On Fri, Sep 13, 2019, 3:10 PM Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> Lots of drama on internals lately. Not that different from 15-20 years ago. > A couple of things to keep in mind for everyone. > > It is not that hard to write a tool that perfectly fits your own needs and > people who are very similar to you in terms of skillset, background and > overall experience. What PHP has always strived to do is to be much broader > than that. Writing a tool that is very approachable to beginners that can > still scale to some of the largest sites in the world is a much harder and > more interesting problem and requires some compromises on both ends. > > The people writing the code get to call the shots, for better or worse. In > the beginning I called all the shots. As more people started to contribute > it took me a while to let go and accept contributions I didn't agree with. > We wouldn't be here today if I hadn't done that.
Sorry if I'm asking the wrong question, was this quote/line intended for Zeev? Since the people currently writing the code(majority of them) are calling some shots lately and he don't seem to want to agree to any of it democratically. -Rasmus
>
  107178
September 16, 2019 19:32 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Sep 13, 2019 at 4:11 PM Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> Lots of drama on internals lately. Not that different from 15-20 years ago. > A couple of things to keep in mind for everyone. > > It is not that hard to write a tool that perfectly fits your own needs and > people who are very similar to you in terms of skillset, background and > overall experience. What PHP has always strived to do is to be much broader > than that. Writing a tool that is very approachable to beginners that can > still scale to some of the largest sites in the world is a much harder and > more interesting problem and requires some compromises on both ends. > > The people writing the code get to call the shots, for better or worse. In > the beginning I called all the shots. As more people started to contribute > it took me a while to let go and accept contributions I didn't agree with. > We wouldn't be here today if I hadn't done that.
Thanks for chiming in Rasmus. A few brief thoughts on recent discussions: * The RFC process encompasses language changes (breaking or non-breaking), as well as policy and process decisions. We have a very wide selection of precedent cases that affirm this. * The "undefined variables" vote that sparked the current controversy currently sits at 29 in favor of exception and 20 against. That's significantly below the acceptance threshold for RFCs. Things are working as they should: The question has been discussed, put up to vote, and the vote has decided against this course of action (as of this writing, though I expect this to be representative of the final result.) * If people still feel that the acceptance bar for RFCs is too low, it may be increased through an RFC. In fact, we already did so this year, which was great. If anyone wants to pursue this, I recommend raising the threshold in general, as defining what constitutes a "significant" backwards compatibility break is fairly hard and will be prone to argument. * As a personal failure, I should have made the voting option for "undef vars throw exception" be "undef vars throw warning in PHP 8 and exception in PHP 9", which would have provided for a long-term migration timeline for affected code. I apologize for pushing an unnecessarily aggressive option here. * Discussion threads on this mailing list have been very unpleasant recently. I am unwilling to actively participate in them in this form. This is bad for everyone, but particularly for opponents of proposals. It means that we cannot establish the necessary discourse to explore improvements or alternatives. The recent propensity to suppress certain discussion topics entirely, as well as the use of overwhelming quantity to disproportionately push a position, contribute to the unproductive discussion environment. Regards, Nikita
  107185
September 17, 2019 08:42 cschneid@cschneid.com (Christian Schneider)
Am 16.09.2019 um 21:32 schrieb Nikita Popov ppv@gmail.com>:
> Thanks for chiming in Rasmus. A few brief thoughts on recent discussions: > > * The RFC process encompasses language changes (breaking or non-breaking), > as well as policy and process decisions. We have a very wide selection of > precedent cases that affirm this.
It feels to me that it gradually changed into that. And while the initial RFCs seemed innocuous policy and process decisions they are now used as a precedent. Should the first non-technical RFCs have been examined more closely due to this? Maybe. But just because it wasn't done doesn't mean the situation cannot be reassessed again. Just because there are now policy and process RFCs does not mean we could take a step back and limit RFCs again. Just to be clear: I'm not demanding anything, I'm just wary of the "that's just the way it is, look at previous examples" argument.
> * The "undefined variables" vote that sparked the current controversy > currently sits at 29 in favor of exception and 20 against. That's > significantly below the acceptance threshold for RFCs. Things are working > as they should: The question has been discussed, put up to vote, and the > vote has decided against this course of action (as of this writing, though > I expect this to be representative of the final result.)
I agree but disagree at the same time: First of all the discussion was unpleasant which I don't see as "working as it should". And while I do think the discussion about undefined variables did clear some things up I also think it distracted from other points in the RFC. I personally chose my battle to focus on undefined variables because it was the biggest pain point. But there are lots of other conversions to Exceptions which were left in the main bulk of things even though they have similarities with undefined variables. A foreach over null might indicate a problem but it is well defined and might occur in correctly working code. Yes, a warning might be appropriate but stopping execution is a different beast again.
> * As a personal failure, I should have made the voting option for "undef > vars throw exception" be "undef vars throw warning in PHP 8 and exception > in PHP 9", which would have provided for a long-term migration timeline for > affected code. I apologize for pushing an unnecessarily aggressive option > here.
Maybe it was quite the opposite: It forced the discussion to happen now. And while it was unpleasant I'm worried that otherwise it would have legitimised making undefined variables an Exception because "we already promoted it to a warning so we all agree that it is bad" which would be wrong. Sure, maybe by the time PHP 9 comes around people agree that an Exception is the right thing to do. But using warnings as a door-opener for exceptions is something to be considered very carefully. - Chris
  107195
September 17, 2019 19:55 php@duncanc.co.uk (Craig Duncan)
On Tue, 17 Sep 2019, 09:43 Christian Schneider, <cschneid@cschneid.com>
wrote:

> Just because there are now policy and process RFCs does not mean we could > take a step back and limit RFCs again. >
I don't recall seeing anybody suggesting we can't do this. However the established process to limit RFCs would be to propose a new RFC that defines what future RFCs can be used for. I'd also expect that RFC to include a proposal on how future "policy and process" changes would be handled once RFCs had been limited.
>
  107205
September 18, 2019 13:43 claude.pache@gmail.com (Claude Pache)
> Le 16 sept. 2019 à 21:32, Nikita Popov ppv@gmail.com> a écrit : > > * Discussion threads on this mailing list have been very unpleasant > recently. I am unwilling to actively participate in them in this form. This > is bad for everyone, but particularly for opponents of proposals. It means > that we cannot establish the necessary discourse to explore improvements or > alternatives. The recent propensity to suppress certain discussion topics > entirely, as well as the use of overwhelming quantity to disproportionately > push a position, contribute to the unproductive discussion environment. >
The discussion would have been less unpleasant if everyone sought consensus, that is, tried to find a solution that is appropriate for everyone, instead of trying to convince others that their opinion is the right one. There is a qualitative difference between consensus and unanimity. Unanimity means that a solution is preferred by everyone — which is reasonably not possible. Consensus means that a solution is acceptable to everyone, even when it is not the best one for everyone. This is mostly possible, but only if everyone tries to satisfy not only themself, but also the others. But consensus cannot be measured by vote. For example, throwing a TypeError for uninitialised variables cannot reach consensus, because it is not appropriate for those that rely on implicitly initialised variables. Triggering an E_WARNING is nearer to a *possible* consensus. I am not optimistic that there would be a mindset change in the direction of seeking consensus for every participating party of the discussion. However, I am suggesting that if a RFC try to seek a solution that is *at least* acceptable to everyone, there will be less frustration and less irritation from the minority. —Claude
  107206
September 18, 2019 13:51 chasepeeler@gmail.com (Chase Peeler)
On Wed, Sep 18, 2019 at 9:43 AM Claude Pache pache@gmail.com> wrote:

> > > > Le 16 sept. 2019 à 21:32, Nikita Popov ppv@gmail.com> a écrit : > > > > * Discussion threads on this mailing list have been very unpleasant > > recently. I am unwilling to actively participate in them in this form. > This > > is bad for everyone, but particularly for opponents of proposals. It > means > > that we cannot establish the necessary discourse to explore improvements > or > > alternatives. The recent propensity to suppress certain discussion topics > > entirely, as well as the use of overwhelming quantity to > disproportionately > > push a position, contribute to the unproductive discussion environment. > > > > > The discussion would have been less unpleasant if everyone sought > consensus, that is, tried to find a solution that is appropriate for > everyone, instead of trying to convince others that their opinion is the > right one. > > There is a qualitative difference between consensus and unanimity. > Unanimity means that a solution is preferred by everyone — which is > reasonably not possible. Consensus means that a solution is acceptable to > everyone, even when it is not the best one for everyone. This is mostly > possible, but only if everyone tries to satisfy not only themself, but also > the others. But consensus cannot be measured by vote. > > For example, throwing a TypeError for uninitialised variables cannot reach > consensus, because it is not appropriate for those that rely on implicitly > initialised variables. Triggering an E_WARNING is nearer to a *possible* > consensus. > > I am not optimistic that there would be a mindset change in the direction > of seeking consensus for every participating party of the discussion. > However, I am suggesting that if a RFC try to seek a solution that is *at > least* acceptable to everyone, there will be less frustration and less > irritation from the minority. > > You've hit the nail on the head. I can't speak for everyone, but I know the
while both Zeev and myself did not like most* of the ideas proposed in the RFC, we both had mentioned the idea of making them opt-in as a possible compromise. That proposal was flat out rejected. At the same time, we do have to be realistic and realize that sometimes a compromise solution isn't feasible or the way to go. If one side wants to build a 100 yard bridge to an island, and the other side doesn't want to build the bridge at all, compromising and building a 50 yard bridge isn't a good solution. * I say most, because there are a few things that we were OK with - which goes back to something else Zeev mentioned, which is not putting so many changes into a single RFC and/or a separate vote for each proposed change. I personally favor limiting the number of changes in an RFC because I think it's hard to focus the discussion, even if the votes are separated out.
> —Claude
-- Chase Peeler chasepeeler@gmail.com