Hey Andreas, > 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.
`: void` on constructor/destructor also helps to explicitly show the developer's intention to not return a value. > There are conventions or popular preference, and there are people or projects which want to do things their own way. And here's another reason why letting `: void` is a good idea. PHP should not enforce conventions but at most recommend them and allow the community to have the freedom of choice. > 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) And why that matters? Everyone knows that the `__toString` method returns a `string` and everyone knows that the `__clone` method returns a `void`. In both those cases, adding an explicit return type is allowed. > But here there are actual technical arguments why someone might prefer one or the other solution I never said that I was referring to people having technical arguments? Anyways, this is not relevant to the RFC > 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. Again, I'm not sure what you're referring to. Best regards, Benas On Thu, Jun 18, 2020, 11:49 PM Andreas Hennings <andr...@dqxtech.net> wrote: > > > 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. >> > > > 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 > >>
