Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110673
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>
 <VI1PR02MB47037B983141D264874BB31BE29B0@VI1PR02MB4703.eurprd02.prod.outlook.com>
 <CANeKSiTLb+UPUjUMnir8TW6GFQXu8nsp_qRsji3JO5e7o3ufUg@mail.gmail.com> <CAB-BujY1moteJVmr6rcVF4yM=REpdANC=hLwWt-+EZWq9ALZqQ@mail.gmail.com>
In-Reply-To: <CAB-BujY1moteJVmr6rcVF4yM=REpdANC=hLwWt-+EZWq9ALZqQ@mail.gmail.com>
Date: Thu, 18 Jun 2020 23:29:05 +0300
Message-ID: <CANeKSiRX0ba15CzVa0qeqd_+C6-5E4kUtKiOWxUOkar-GJY5nw@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="000000000000897fe605a861a1f1"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors
 return void
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000897fe605a861a1f1
Content-Type: text/plain; charset="UTF-8"

Hey Andreas,

It seems that you actually haven't read my reply carefully enough.

> But this distinction would only apply in PHP 8. And the only difference
here
is whether returning a value is just deprecated or fully illegal.
> In PHP 9, constructors with ": void" would be the same as without ":
void".
So long term it will become a "meaningless choice".
>
> Or what am I missing?

The "allowance" of `void` return type will help:
- to be more explicit.
- to enforce `void` rules on constructors/destructors (in PHP 8).
- to be more consistent with other methods (which is what people like the
most
about allowing `void` on ctor/dtor based on r/php).
- to be more consistent with the documentation.

> Except consistency with existing constructors in other packages which
choose
to not add ": void" to constructors.
>
> Either it is enforced in a "code convention", or it is up to every single
developer and team, and we get silly arguments between developers in code
review whether or not this should be added. Or we get git noise because one
developer adds those declarations, and another removes them.

I find these comments of yours to make completely no sense since most of the
additions to PHP will create some sort of silly arguments between
developers.

A best example would be the `mixed` type. Based on what you have said, this
pseudo type will create inconsistencies because some libraries will have
parameters explicitly declared as `mixed` while others - won't. It will also
create arguments between developers on whether they should use it or not.

Moving on, let's take the `void` type (implemented in PHP 7.1) as another
great
example! Laravel and Symfony (both depend on PHP 7.2) don't use it while
other
libraries - do. So, as I understand based on your comments, this is creating
inconsistencies and arguments between developers. Some say `void` should be
added, some say not. Some libraries declare it, some don't.

Moving on, attributes. If you go onto Reddit, you can see that the crowd is
divided 50/50. Some believe that attributes are bad and say that they will
use
functions (for "adding" metadata) instead. Others prefer attributes and will
use those. You can literally find people bashing each other for their
preference. So that is creating heated arguments AND possibly future
inconsistencies between different people/libraries.

It's not possible to be "politically" neutral. Every single feature/code
style
is used by some group of people and isn't used by another. So next time
please
be more pragmatic.

> So if you want to support PHP 7, you cannot add ": void".
> If you only care about PHP 9, you don't need to add ": void" because it is
pointless.
>
> Any convention would probably discourage it to be more universally usable.

This is a completely contradicting statement. Just a few sentences ago you
said
that there will be silly arguments between people. But now as I understand,
most conventions will probably discourage the explicit `: void` return type
on
constructors/destructors. Thus, since most people follow conventions, there
will be little-to-no arguments.

> Exactly my point. "Optional" means people will make arbitrary choices and
argue about it, or look for a convention.

Already addressed this.

Best regards,
Benas

On Thu, Jun 18, 2020, 11:15 PM Andreas Hennings <andreas@dqxtech.net> wrote:

>
> On Thu, 18 Jun 2020 at 18:33, Benas IML <benas.molis.iml@gmail.com> wrote:
>
>> 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.
>>
>> Ok. I read more carefully now.
>
> But this distinction would only apply in PHP 8. And the only difference
> here is whether returning a value is just deprecated or fully illegal.
> In PHP 9, constructors with ": void" would be the same as without ": void".
> So long term it will become a "meaningless choice".
>
> Or what am I missing?
>
>
>
>> And well, the explicit `: void` declaration also helps your code to be
>> more consistent with other methods ;)
>>
>
> Except consistency with existing constructors in other packages which
> choose to not add ": void" to constructors.
>
>
>>
>> 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.
>>
>
> Either it is enforced in a "code convention", or it is up to every single
> developer and team, and we get silly arguments between developers in code
> review whether or not this should be added. Or we get git noise because one
> developer adds those declarations, and another removes them.
>
>
>>
>> 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).
>>
>
> So if you want to support PHP 7, you cannot add ": void".
> If you only care about PHP 9, you don't need to add ": void" because it is
> pointless.
>
> Any convention would probably discourage it to be more universally usable.
>
>
>
>>
>> Last but not least, just to reiterate, the `: void` return type is
>> optional and you don't need to specify it.
>>
>
> Exactly my point. "Optional" means people will make arbitrary choices and
> argue about it, or look for a convention.
>
> Greetings
> Andreas
>
>
>
>>
>> Best regards,
>> Benas
>>
>

--000000000000897fe605a861a1f1--