Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110839
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> <CANeKSiQ6uWncab32jdvhgRdvkGiB+8JN87bQE4RkU5o_q4127A@mail.gmail.com>
In-Reply-To: <CANeKSiQ6uWncab32jdvhgRdvkGiB+8JN87bQE4RkU5o_q4127A@mail.gmail.com>
Date: Fri, 3 Jul 2020 18:21:51 +0300
Message-ID: <CANeKSiRUOAsje21904NDJzaqTDLSaq18oG3sShm-3erBxTe+UA@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="000000000000572da105a98b1686"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000572da105a98b1686
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

*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 <benas.molis.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 <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 urgen=
t to
>> enforce this compatibility break outside of the standard policy.   In fa=
ct,
>> unless I=E2=80=99m missing something, it doesn=E2=80=99t attempt to tack=
le that question at
>> all, and portrays it as a simple choice between two equal options that a=
re
>> up to personal preference.  That is not the case - our standard policy i=
s
>> an outward facing contract, which we should be very wary of breaking - a=
nd
>> 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 =
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 =E2=80=9Cintroduce into PHP 8.=
1,
>> despite our compatibility policy=E2=80=9D, 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=E2=80=99s have to obtain a 2/3 super=
majority.
>>
>> I think those are fairly minor amendments that can be done without
>> restarting the vote, given where it=E2=80=99s at.
>>
>> Zeev
>
>

--000000000000572da105a98b1686--