Re: Ensure correct signatures for PHP magic methods

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