Re: [RFC] [DISCUSSION] Ensure correct magic methods' signatures when typed
| From: | Nicolas Grekas | Date: | Tue, 14 Apr 2020 14:54:13 +0000 |
| Subject: | Re: [RFC] [DISCUSSION] Ensure correct magic methods' signatures when typed | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-109633@lists.php.net to get a copy of this message | ||
> No, *nothing* is gonna be mandatory.
>
> As per the RFC:
>
> > This RFC proposes to introduce the following signatures checks when
> magic methods are typed:
>
> These checks are only gonna be performed when you type your signatures and
> *only when you type*. So, your example:
__call($name,
> $arguments) will
> work just fine, same as if you don't type __clone with
> : void.
>
> Is there a better way to phrase that in the RFC?
>
OH, good news then. This should be formulated with more sentences I think,
e.g:
> When any of the listed magic method use type hints, this RFC will enforce
that only the supported types are used.
> When they don't declare a type, nothing specific will happen.
Also, add this somewhere maybe:
> This limits the BC break to methods that declare a wrong type.
Because this is what this is about, right?
> Thanks for raise this. Nowadays, you can't: XÈl¬N
> ! %ðí)Brhttps://3v4l.org/pPJDt. But,
> if you call as a method, yes: https://3v4l.org/0VmYQ.
>
> So this should be documented in the RFC as a BC Break.
>
Yes, the BC break is bigger when the magic methods are used directly,
that's true and should be mentioned to.
> And the BIG question: is all this worth the BC break?
>>
>
> My main motivation is to make sure that developers are using the magic
> methods with the correct type, nothing else. If everyone then agrees that
> not having these checks is better for the language, no problem on closing
> this RFC :)
>
Now that I understand that the scope of the BC break is quite narrow, I
think you answered the question on my side.
I'm just not sold on allowing "void" on __construct, because the very
concept of a return type on a constructor is ... void, and also because of
the code style choices this will open (and the CS "wars" I mentioned).
Thanks,
Nicolas