Re: [RFC] [DISCUSSION] Ensure correct magic methods' signatures when typed
| From: | Gabriel Caruso | Date: | Sat, 11 Apr 2020 20:40:59 +0000 |
| Subject: | Re: [RFC] [DISCUSSION] Ensure correct magic methods' signatures when typed | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-109588@lists.php.net to get a copy of this message | ||
On Tue, 7 Apr 2020 at 12:55, Claude Pache <claude.pache@gmail.com> wrote:
>
> Le 5 avr. 2020 à 16:01, Gabriel Caruso <carusogabriel34@gmail.com> a
> écrit :
>
> Hello, internals.
>
> Hereby you can find the RFC Document that I want to discuss as suggested
> via https://externals.io/message/109416 and
> https://externals.io/message/107990:
>
> https://wiki.php.net/rfc/magic-methods-signature
>
> Best regards,
>
> -- Gabriel Caruso
>
>
> Hi,
>
Hello Claude,
>
> Regarding __construct(), etc. Since those methods are not supposed to
> return anything, they ought to accept the
void return
> pseudo-type in
> their signature, which means exactly that: “do not return anything”. I
> consider that the current behaviour (i.e., not accepting the :
> void
> signature) as a bug, and was very surprised when I stumbled on it.
>
>
I'll add to the RFC adding the possibility of typing the __construct() as
: void as one of the changes.
> ------------
>
> Also, I raise the following question:
>
> Should omitted types be added implicitly? I.e., if I write: `function
> __toString() { } should the compiler interpret it as function
> __toString(): string { }` ? (Currently, it is not the case.)
>
> Doing so would raise BC concerns for some, uh, creative uses of magic
> methods. On the other hand, that may help to add progressively type
> informations on magic methods, since there is no need to synchronise
> manually classes and subclasses (the compiler would do it automatically for
> you). Concrete example here: https://3v4l.org/hTMvA
>
>
This RFC does not cover analyzing the return of magic methods nor adding
simplicity types. I'll add a note about it in the RFC.
> —Claude
>
Thanks!