Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors returnvoid

This is only part of a thread. view whole thread
  110837
July 3, 2020 15:05 zeev@zend.com (Zeev Suraski)
> On 3 Jul 2020, at 13:27, Nikita Popov ppv@gmail.com> wrote: > > Now, whether this RFC actually makes a sufficient case to disregard policy > here is a different question, and at the discretion of the voters.
I think this is key here (the first part, not the second). It doesn’t seem as if the RFC makes any case at all why it urgent to enforce this compatibility break outside of the standard policy. In fact, unless I’m missing something, it doesn’t attempt to tackle that question at all, and portrays it as a simple choice between two equal options that are up to personal preference. That is not the case - our standard policy is an outward facing contract, which we should be very wary of breaking - and at the very least do while taking a very informed, measured decision. We can not assume that all voters fully understand the implications of breaking the policy, or even that this would be breaking policy at all, given that it’s not even mentioned in the RFC. As such, I do think the current state of the RFC is somewhat problematic, and to actually consider introducing it into 8.1, the RFC requires 3 amendments: 1. State that per policy, if the RFC is passed - it would generally go into PHP 9.0. 2. Make the case of why the RFC author believes it’s important to do it in 8.1 and not wait for 9.0 per our public-facing policy. 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, despite our compatibility policy”, and turn it into a clear Yes/No question that clearly requires a 2/3 majority. Since technically it might be an issue, perhaps we can stick with the current wording, but still make it clear that for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. I think those are fairly minor amendments that can be done without restarting the vote, given where it’s at. Zeev
  110838
July 3, 2020 15:20 benas.molis.iml@gmail.com (Benas IML)
Hey Zeev,

For me it doesn't really matter if we enforce `void` rules implicitly in
PHP 8.1 or PHP 9.0. Just that we do at some point.

Thus, I'm okay with closing the secondary vote and updating the RFC to
mention only PHP 9.0 (and not PHP 8.1).

Best regards,
Benas Seliuginas

On Fri, Jul 3, 2020, 6:05 PM Zeev Suraski <zeev@zend.com> wrote:

> > > On 3 Jul 2020, at 13:27, Nikita Popov ppv@gmail.com> wrote: > > > > Now, whether this RFC actually makes a sufficient case to disregard > policy > > here is a different question, and at the discretion of the voters. > > I think this is key here (the first part, not the second). > > It doesn’t seem as if the RFC makes any case at all why it urgent to > enforce this compatibility break outside of the standard policy. In fact, > unless I’m missing something, it doesn’t attempt to tackle that question at > all, and portrays it as a simple choice between two equal options that are > up to personal preference. That is not the case - our standard policy is > an outward facing contract, which we should be very wary of breaking - and > at the very least do while taking a very informed, measured decision. > > We can not assume that all voters fully understand the implications of > breaking the policy, or even that this would be breaking policy at all, > given that it’s not even mentioned in the RFC. > > As such, I do think the current state of the RFC is somewhat problematic, > and to actually consider introducing it into 8.1, the RFC requires 3 > amendments: > > 1. State that per policy, if the RFC is passed - it would generally go > into PHP 9.0. > 2. Make the case of why the RFC author believes it’s important to do it > in 8.1 and not wait for 9.0 per our public-facing policy. > 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, despite > our compatibility policy”, and turn it into a clear Yes/No question that > clearly requires a 2/3 majority. Since technically it might be an issue, > perhaps we can stick with the current wording, but still make it clear that > for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. > > I think those are fairly minor amendments that can be done without > restarting the vote, given where it’s at. > > Zeev
  110839
July 3, 2020 15:21 benas.molis.iml@gmail.com (Benas IML)
*just let me know if that is a minor change and I'm okay with updating the
RFC right now.

Best regards,
Benas Seliuginas

On Fri, Jul 3, 2020, 6:20 PM Benas IML iml@gmail.com> wrote:

> Hey Zeev, > > For me it doesn't really matter if we enforce `void` rules implicitly in > PHP 8.1 or PHP 9.0. Just that we do at some point. > > Thus, I'm okay with closing the secondary vote and updating the RFC to > mention only PHP 9.0 (and not PHP 8.1). > > Best regards, > Benas Seliuginas > > On Fri, Jul 3, 2020, 6:05 PM Zeev Suraski <zeev@zend.com> wrote: > >> >> > On 3 Jul 2020, at 13:27, Nikita Popov ppv@gmail.com> wrote: >> > >> > Now, whether this RFC actually makes a sufficient case to disregard >> policy >> > here is a different question, and at the discretion of the voters. >> >> I think this is key here (the first part, not the second). >> >> It doesn’t seem as if the RFC makes any case at all why it urgent to >> enforce this compatibility break outside of the standard policy. In fact, >> unless I’m missing something, it doesn’t attempt to tackle that question at >> all, and portrays it as a simple choice between two equal options that are >> up to personal preference. That is not the case - our standard policy is >> an outward facing contract, which we should be very wary of breaking - and >> at the very least do while taking a very informed, measured decision. >> >> We can not assume that all voters fully understand the implications of >> breaking the policy, or even that this would be breaking policy at all, >> given that it’s not even mentioned in the RFC. >> >> As such, I do think the current state of the RFC is somewhat problematic, >> and to actually consider introducing it into 8.1, the RFC requires 3 >> amendments: >> >> 1. State that per policy, if the RFC is passed - it would generally go >> into PHP 9.0. >> 2. Make the case of why the RFC author believes it’s important to do it >> in 8.1 and not wait for 9.0 per our public-facing policy. >> 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, >> despite our compatibility policy”, and turn it into a clear Yes/No question >> that clearly requires a 2/3 majority. Since technically it might be an >> issue, perhaps we can stick with the current wording, but still make it >> clear that for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. >> >> I think those are fairly minor amendments that can be done without >> restarting the vote, given where it’s at. >> >> Zeev > >