Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110664
MIME-Version: 1.0
References: <CANeKSiTAYFOUvA+V+Ytb=N91OPMv_iuJ1m6iFq2kPE80Qp0QJw@mail.gmail.com>
 <VI1PR02MB4703313585C4A88D85068462E29B0@VI1PR02MB4703.eurprd02.prod.outlook.com>
 <CANeKSiQjkMMWiA8K+xRGO3Bmdo+vpQcOQoOnCP2Oxya8i8AB3A@mail.gmail.com>
In-Reply-To: <CANeKSiQjkMMWiA8K+xRGO3Bmdo+vpQcOQoOnCP2Oxya8i8AB3A@mail.gmail.com>
Date: Thu, 18 Jun 2020 18:02:21 +0200
Message-ID: <CAB-BujZrGGbEkOv3PaADp9Gt1EKZc83E9a+H91MGBbjZZfYJBw@mail.gmail.com>
To: Benas IML <benas.molis.iml@gmail.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007a14e605a85de739"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors
 return void
From: andreas@dqxtech.net (Andreas Hennings)

--0000000000007a14e605a85de739
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.iml@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 ar=
e
> a couple of examples that show that no magic method is ever supposed to b=
e
> 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 <bobwei9@hotmail.com> wrote:
>
> > > Am 17.06.2020 um 01:10 schrieb Benas IML <benas.molis.iml@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 most=
ly
> > void, so let's enforce it =E2=80=A6 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
>

--0000000000007a14e605a85de739--