Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110838
MIME-Version: 1.0
References: <CANeKSiRe95yUeyUV5S3MU1Bzh7A_Z0OQF_WVNFK16CcbE5wYqw@mail.gmail.com>
 <CAEPJdumDhFEFKNbYR5PTg5YE8H8oO960ed4DU_wUci_mRX0X6Q@mail.gmail.com>
 <CAF+90c_L5_moki0mqGyxPE5cMG0bUZPaN3OzO0xx8dHTUkK1tA@mail.gmail.com> <75DFD68A-BC67-4527-B5BB-110DE18DCA2A@zend.com>
In-Reply-To: <75DFD68A-BC67-4527-B5BB-110DE18DCA2A@zend.com>
Date: Fri, 3 Jul 2020 18:20:12 +0300
Message-ID: <CANeKSiQ6uWncab32jdvhgRdvkGiB+8JN87bQE4RkU5o_q4127A@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Benjamin Eberlei <kontakt@beberlei.de>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000074a28805a98b1046"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
From: benas.molis.iml@gmail.com (Benas IML)

--00000000000074a28805a98b1046
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 <nikita.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=E2=80=99t seem as if the RFC makes any case at all why it urgent=
 to
> enforce this compatibility break outside of the standard policy.   In fac=
t,
> unless I=E2=80=99m missing something, it doesn=E2=80=99t attempt to tackl=
e that question at
> all, and portrays it as a simple choice between two equal options that ar=
e
> 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 - an=
d
> 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=E2=80=99s 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=E2=80=99s important t=
o 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 =E2=80=9Cintroduce into PHP 8.1=
, despite
> our compatibility policy=E2=80=9D, and turn it into a clear Yes/No questi=
on 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 th=
at
> for 8.1 to be chosen, it=E2=80=99s 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=E2=80=99s at.
>
> Zeev

--00000000000074a28805a98b1046--