On Thu, 18 Jun 2020 at 22:29, Benas IML <benas.molis....@gmail.com> 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 <andr...@dqxtech.net> > wrote: > >> >> On Thu, 18 Jun 2020 at 18:33, Benas IML <benas.molis....@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 >>> >>
