Hi The RFC introduces what I call a "meaningless choice", by making something possible that is currently illegal, but which does not change behavior. https://3v4l.org/daeEm
It forces organisations, frameworks or the php-fig group to introduce yet another coding convention to decide whether or not there should be a ": void" declaration on constructors. I am ok with restricting the use of "return *;" inside a constructor. But I don't like allowing the ": void" declaration. Greetings On Thu, 18 Jun 2020 at 17:18, Benas IML <benas.molis....@gmail.com> wrote: > Hey Bob, > > Magic methods are **never** supposed to be called directly (even more if > that method is a constructor or a destructor). If that's not the case, it's > just plain bad code. But by enforcing these rules, we make sure that less > of that (bad code) is written and as a result, we make PHP code less > bug-prone and easier to debug. That's also most likely the reason why > "ensure magic methods' signature" RFC opted in to validate `__clone` > method's signature and ensure that it has `void` return type. > > Just for the sake of making sure that you understand what I mean, here are > a couple of examples that show that no magic method is ever supposed to be > called directly: > ```php > // __toString > (string) $object; > > // __invoke > $object(); > > // __serialize > serialize($object); > ``` > > Moreover, by validating constructors/destructors and allowing an explicit > `void` return type declaration, we are becoming much more consistent > (something that PHP is striving for) with other magic methods (e. g. > `__clone`). > > Also, saying that "sometimes you have valid information to pass from the > parent class" is quite an overstatement. After analyzing most of the 95 > Composer packages that had a potential BC break, I found out that either > they wanted to return early (that is still possible to do using `return;`) > or they added a `return something;` for no reason. Thus, no libraries > actually returned something useful and valid from a constructor (as they > shouldn't). > > Last but certainly not least, constructors have one and only one > responsibility - to initialize an object. Whether you read Wikipedia's or > PHP manual's definition, a constructor does just that. It initializes. So, > the PHP manual is perfectly correct and documents the correct return type > that a constructor should have. > > Best regards, > Benas > > On Thu, Jun 18, 2020, 4:06 PM Bob Weinand <bobw...@hotmail.com> wrote: > > > > Am 17.06.2020 um 01:10 schrieb Benas IML <benas.molis....@gmail.com>: > > > > > > Hey internals, > > > > > > This is a completely refined, follow-up RFC to my original RFC. Based > on > > the > > > feedback I have received, this PR implements full validation and > > implicitly > > > enforces `void` rules on constructors/destructors while also allowing > to > > > declare an **optional** explicit `void` return type. Note, that there > is > > a > > > small but justifiable BC break (as stated by the RFC). > > > > > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > > > > > Best regards, > > > Benas Seliuginas > > > > Hey Benas, > > > > I do not see any particular benefit from that RFC. > > > > Regarding what the manual states - the manual is wrong there and thus > > should be fixed in the manual. This is not an argument for changing > engine > > behaviour. > > > > Sometimes a constructor (esp. of a parent class) or destructor may be > > called manually. Sometimes you have valid information to pass from the > > parent class. > > With your RFC an arbitrary restriction is introduced necessitating an > > extra method instead. > > > > In general that RFC feels like "uh, __construct and __destruct are mostly > > void, so let's enforce it … because we can"? > > > > On these grounds and it being an additional (albeit mostly small) > > unnecessary BC break, I'm not in favor of that RFC. > > > > Bob >
