Re: [RFC] [DISCUSSION] Ensure correct magic methods' signatures when typed

From: 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

« previous php.internals (#109633) next »