Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110674 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10210 invoked from network); 18 Jun 2020 22:03:59 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Jun 2020 22:03:59 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4A7A21804FD for ; Thu, 18 Jun 2020 13:50:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 18 Jun 2020 13:49:59 -0700 (PDT) Received: by mail-oi1-f177.google.com with SMTP id j189so6349640oih.10 for ; Thu, 18 Jun 2020 13:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dqxtech-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x4RJ22RnUCGbem4Fl+9iW3IohErFshL0p9TcgUBTlnU=; b=rz5MsIoNUByj1od5h+TCVuTCBQm3X8vtsBlWaC+Q8cb4Jd3NqN0wGEy9SiNTgH1BWR 29yXUmZY6Y8BkRFw3FD/TKYAfRHEqePtSxu8I/9/uDC8AidaRxF/gbCRGFchtlJmR+Ep 64QSS3T6savj/hrwhWGd9gx2+LFB1pBahZDYtZx6zgjlpqltp1m2hMBTPC30k4tS5vTf Jp0lEfwBQvMq7pdBvPxVgJjdc1nATu0nEwoHssoX2E8FkVUiE/rz8PLGfMcECi8q31K1 bD6TqEXcVzb6mA7e5qXqJJnPxqdVoe8Gmsmh88bCgRyisFQDx6kd7VYijXClx4H+zslj cvdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x4RJ22RnUCGbem4Fl+9iW3IohErFshL0p9TcgUBTlnU=; b=AnBtyDL/IH8hy6IHXcwC8LLZZ/x0E9h/hQ4YHTfG+UpDvyQCNmA/t/b/o4ltwlgc4X LNBo8LjkHEj6x9MNLVk6CGWFnHmOYVsHW3VXZRnADqnewVjwSeGMhIZI+phW0Nhbued9 qa0Lhk3p/4M0XSTGM0qjo7Zm0pW+f8oQmRvVBL8ZgP28Nkp/7+lk5S4IzCjBmn/XUt4d mV+ybhmA9bfZl/D/x5p305UrWTPRxzZ1B3Z/uKdXFkV57JrQjBcGAtBNgW0IdiZ5aHRE aRo7xTmPC4ceod3RQoelT+K4Tjv46u5JuC40KhYEsXwNXYd/kK9bMUh9kfonPE8V6k38 PKnw== X-Gm-Message-State: AOAM530P3IyBV2MinDmSJjqMPTLb8wevpGnEUdWTaq+MmGggEvBxOnxg Vc3T5zWl7GQpZZKE4og99fTUq46F5v0NqHbxn07tow== X-Google-Smtp-Source: ABdhPJwdhV0EcNfJLwPXtkyp5JH+mtaSP6Z0L0QXhdVsqSDn2H0zE/jeuH/Jb/2DCLxlxMwuHvbtjLqdmnaIgKWh8xw= X-Received: by 2002:a54:4401:: with SMTP id k1mr571625oiw.97.1592513397617; Thu, 18 Jun 2020 13:49:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 18 Jun 2020 22:49:46 +0200 Message-ID: To: Benas IML Cc: Bob Weinand , PHP Internals List Content-Type: multipart/alternative; boundary="0000000000005d8df605a861eba2" Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void From: andreas@dqxtech.net (Andreas Hennings) --0000000000005d8df605a861eba2 Content-Type: text/plain; charset="UTF-8" On Thu, 18 Jun 2020 at 22:29, Benas IML wrote: > 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. > Another example would be the "public" access specifier, which can be omitted and the method will still be public. There is a major difference though: If you look at a method without "public", or a parameter without "mixed", there is a chance that the developer actually should have put something else here, e.g. "private" or "string", and was simply too lazy, was not aware of that possibility, or wrote the code with a prior PHP version in mind. Having the explicit keyword documents an intentional choice to make the method public, to make the parameter mixed, etc. On the other hand, for a constructor the ": void" is just stating the obvious. Even if you see a constructor without ": void", you still know that this is not meant to return anything. Either because it is generally agreed to be bad (PHP7) or because it is deprecated (PHP8) or because it is illegal (PHP9) > > 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. > But here there are actual technical arguments why someone might prefer one or the other solution. > > 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. > There are conventions or popular preference, and there are people or projects which want to do things their own way. And of course there is the time before agreements are reached in specific conventions, where people produce code which could be one way or the other. I don't see a contradiction here. Greetings Andreas > > 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 > wrote: > >> >> On Thu, 18 Jun 2020 at 18:33, Benas IML >> 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 >>> >> --0000000000005d8df605a861eba2--