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

This is only part of a thread. view whole thread
  110832
July 3, 2020 10:26 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Jul 3, 2020 at 11:04 AM Benjamin Eberlei <kontakt@beberlei.de>
wrote:

> On Thu, Jul 2, 2020 at 11:12 PM Benas IML iml@gmail.com> > wrote: > > > Hey internals, > > > > I have opened the voting for the RFC, let's hope everything is going > > to be smooth :). If you have any other questions, let me know! > > > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > > > Best regards, > > Benas Seliuginas > > > > Hi Benas, > > I wanted to raise what I believe is an issue with the secondary vote going > against PHP policy to introduce a BC break in 8.1, I would imagine policy > overrules voting decision here and it wouldn't matter what people voted > for, it will only be removed at the earliest in 9.0 >
To answer the policy question: RFCs can override or change general policy -- after all, policy is decided through the RFC process itself. To give a precedent where this happened for a "pure" BC break: https://wiki.php.net/rfc/too_few_args But more generally, many RFCs will have "minor" BC breaks as part of a larger proposal, and RFC acceptance also always implies that we consider those BC breaks acceptable for the targeted PHP version. Now, whether this RFC actually makes a sufficient case to disregard policy here is a different question, and at the discretion of the voters. Regards, Nikita
  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 > >