Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110665
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> <CAB-BujZrGGbEkOv3PaADp9Gt1EKZc83E9a+H91MGBbjZZfYJBw@mail.gmail.com>
In-Reply-To: <CAB-BujZrGGbEkOv3PaADp9Gt1EKZc83E9a+H91MGBbjZZfYJBw@mail.gmail.com>
Date: Thu, 18 Jun 2020 19:33:26 +0300
Message-ID: <CANeKSiRbA9Cj0b8HJk9MZBO-opVrGZOcYYMy-KxLiZr6Sb33Kw@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c9d27105a85e56a8"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors
 return void
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000c9d27105a85e56a8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Andreas,

That is incorrect. Adding an explicit `: void` does change behavior since
only then the check (whether something is being returned) is enforced. This
allows PHP 8 projects to take advantage of this enforcement while being
respective to older codebases.

And well, the explicit `: void` declaration also helps your code to be more
consistent with other methods ;)

Without an explicit `: void` return type declaration, `void` rules are not
enforced on constructors/destructors and will not be until PHP 9.0 (which
will probably release in 5 years).

Moreover, saying "it forces organisations, frameworks or the php-fig group
to introduce yet another coding convention" is a complete exaggeration. In
fact, even now there are no PSR conventions that specify how and when to
write parameter/return/property type hints.

Also, it's important to understand that PHP libraries are really really
slow at starting to **depend** on new PHP versions. It will probably take a
few good years (if not more) until first few libraries start requiring PHP
8.0. As a matter of fact, even Symfony framework is still requiring PHP
7.2.5 and cannot take advantage of its newer features (e. g. typed
properties).

Last but not least, just to reiterate, the `: void` return type is optional
and you don't need to specify it.

Best regards,
Benas

On Thu, Jun 18, 2020, 7:02 PM Andreas Hennings <andreas@dqxtech.net> wrote:

> Hi
>
> The RFC introduces what I call a "meaningless choice", by making somethin=
g
> 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 les=
s
>> 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 a=
re
>> 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 explici=
t
>> `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 o=
r
>> PHP manual's definition, a constructor does just that. It initializes. S=
o,
>> the PHP manual is perfectly correct and documents the correct return typ=
e
>> 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. Base=
d
>> on
>> > the
>> > > feedback I have received, this PR implements full validation and
>> > implicitly
>> > > enforces `void` rules on constructors/destructors while also allowin=
g
>> to
>> > > declare an **optional** explicit `void` return type. Note, that ther=
e
>> 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 =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
>>
>

--000000000000c9d27105a85e56a8--