Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108007
MIME-Version: 1.0
References: <CAP=4hCKg2efDty5hsttskG9DiuemhbEvYn1p9PtuUpBAiMr91A@mail.gmail.com>
 <CAFPFaMLp9CeD4NRGjBND6TBYkTCuNAi_5KW2XKervoJVjjuPOw@mail.gmail.com> <CAP=4hCJd4asnooF_D5GkGZk1GFjcmCDmJNW6YYyMuC7Dwgv4cA@mail.gmail.com>
In-Reply-To: <CAP=4hCJd4asnooF_D5GkGZk1GFjcmCDmJNW6YYyMuC7Dwgv4cA@mail.gmail.com>
Date: Mon, 6 Jan 2020 16:10:53 +0100
Message-ID: <CAFPFaM+8VKc9yDgyHuRabMS2H7DMdb5_WH28DSw+XzOPX4bOkw@mail.gmail.com>
To: Gabriel Caruso <carusogabriel34@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000120251059b7a13cb"
Subject: Re: [PHP-DEV] Ensure correct signatures for PHP magic methods
From: george.banyard@gmail.com ("G. P. B.")

--000000000000120251059b7a13cb
Content-Type: text/plain; charset="UTF-8"

On Mon, 6 Jan 2020 at 10:29, Gabriel Caruso <carusogabriel34@gmail.com>
wrote:

> Hello George
>
> On Mon, 6 Jan 2020 at 01:28, G. P. B. <george.banyard@gmail.com> wrote:
>
>> On Sun, 5 Jan 2020 at 18:44, Gabriel Caruso <carusogabriel34@gmail.com>
>> wrote:
>>
>>> Hello Internals,
>>>
>>> I have a PR proposing to start checking the signatures for PHP magic
>>> methods in the next major version of PHP:
>>> https://github.com/php/php-src/pull/4177. The idea for this PR came from
>>> https://bugs.php.net/bug.php?id=69718.
>>>
>>> I'd like to hear your opinion before putting more effort into this :)
>>>
>>> Best regards.
>>>
>>
>> Hello Gabriel,
>>
>> I do like the idea, but I would agree that I'd want void as the return
>> type instead of a no return compile error.
>> Other than that +1 from my side.
>>
>
>
> The reason why I didn't want to go with `__construct(): void`, for
> example, is because some articles that I've read say that Constructors and
> Destructors do not return anything:
>
> - https://www.geeksforgeeks.org/php-constructors-and-destructors/
> - https://docs.phpdoc.org/references/phpdoc/tags/return.html
> - https://stackoverflow.com/questions/11904255/constructor-returning-value
>
> Also, the community has pushing this standard, as it can be seen in
> https://github.com/slevomat/coding-standard#slevomatcodingstandardtypehintsreturntypehint-
> .
>
> Best regards,
>

Well the void return type means no return or an early return, so I would
say that "no return" is a stronger requirement then void, but I think
adding the void return type is a massive BC break as all code which doesn't
define the magic methods as void break ... I didn't think that through as
it seems the no return thing doesn't have that problem, so seems fine by me
however this is done.

Best regards

George P. Banyard

--000000000000120251059b7a13cb--