Re: [PHP-DEV][RFC] Allow void return type variance
Hi I think this is a great idea, and that it should be implemented. On 17/02/2019 16:36, Rowan Collins wrote: Instead, ": void" in PHP represents a *behavioural constraint* on the function - it declares that within this function, anything of the form "return $value" is to be treated as an error. In other languages, the same constraint might be enforced by declaring the routine as a "procedure" rather than a "function". As such, it is more appropriate to compare "void vs non-void" to "static vs non-static", which is an invariant constraint - you can't over-ride a static method with a non-static one, or vice versa. I think this is flawed reasoning. Yes, you can view it as behavioral constraint on the current method, but I do not think that alone is a valid reason to impose the same constraint on all decendants of that class. Yes, "static" is an invaraint constraint, but I think we should consider this "void" constraint differently and not enforce that same invariance. The reason is that is fits very well with the Liskov substitution principle. Any decendant class can be subtituted safely in existing code, even if the decendant should be trying to return something. This also gives the least amount of surprise to a developer after RFC https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters has been implemented. Then developers will expect that return values can be different as long as the Liskov substitution principle holds. Terje Bråten. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Allow void return type variance
I second Rowans thoughts. Am So., 17. Feb. 2019, 17:36 hat Rowan Collins geschrieben: > On 04/02/2019 03:22, Wes wrote: > > Recent events convinced me to write this RFC :P > > > > Please have a read here https://wiki.php.net/rfc/allow-void-variance > > > I was thinking about this this afternoon, and I think the current > behaviour is actually correct, and this constraint should stay invariant. > > My reasoning is that ": void" isn't actually a *type constraint* - there > is no "void type" to apply the rules of covariance and contravariance > to. It's tempting to place it on a par with ": null", but a void > function evaluates to null only for the same reason an unset variable > does: because the runtime has to give you *something*. > > Instead, ": void" in PHP represents a *behavioural constraint* on the > function - it declares that within this function, anything of the form > "return $value" is to be treated as an error. In other languages, the > same constraint might be enforced by declaring the routine as a > "procedure" rather than a "function". > > As such, it is more appropriate to compare "void vs non-void" to "static > vs non-static", which is an invariant constraint - you can't over-ride a > static method with a non-static one, or vice versa. > > > (Incidentally, the RFC mentions TypeScript as precedent; there, "void" > apparently *is* a type, not just a keyword in function signatures: > https://www.typescriptlang.org/docs/handbook/basic-types.html) > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV][RFC] Allow void return type variance
On 04/02/2019 03:22, Wes wrote: Recent events convinced me to write this RFC :P Please have a read here https://wiki.php.net/rfc/allow-void-variance I was thinking about this this afternoon, and I think the current behaviour is actually correct, and this constraint should stay invariant. My reasoning is that ": void" isn't actually a *type constraint* - there is no "void type" to apply the rules of covariance and contravariance to. It's tempting to place it on a par with ": null", but a void function evaluates to null only for the same reason an unset variable does: because the runtime has to give you *something*. Instead, ": void" in PHP represents a *behavioural constraint* on the function - it declares that within this function, anything of the form "return $value" is to be treated as an error. In other languages, the same constraint might be enforced by declaring the routine as a "procedure" rather than a "function". As such, it is more appropriate to compare "void vs non-void" to "static vs non-static", which is an invariant constraint - you can't over-ride a static method with a non-static one, or vice versa. (Incidentally, the RFC mentions TypeScript as precedent; there, "void" apparently *is* a type, not just a keyword in function signatures: https://www.typescriptlang.org/docs/handbook/basic-types.html) Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Allow void return type variance
Hi Wes Den man. 4. feb. 2019 kl. 05.19 skrev Wes : > > Hello PHPeeps! > > Recent events convinced me to write this RFC :P > > Please have a read here https://wiki.php.net/rfc/allow-void-variance > > I am targeting all the supported PHP versions because this is mainly to > placate the discontent that arised by PHPUnit enforcing its users to use > void, so waiting 7.4 doesn't make much sense. I don't like to suddenly change things like that in lower versions. I would be for it for 7.4, but not merging to already active releases branches. That is usually not how we deal with things like this. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Allow void return type variance
Hi! > Recent events convinced me to write this RFC :P > > Please have a read here https://wiki.php.net/rfc/allow-void-variance > > I am targeting all the supported PHP versions because this is mainly to > placate the discontent that arised by PHPUnit enforcing its users to use > void, so waiting 7.4 doesn't make much sense. I was never a big fan of void pseudotype, but since it exists, I think it makes sense to be able to override it. It does not violate the protocol (since it's impossible in PHP for function to not return a value, and it's very implausible anybody relies on void function to return null). And since we have users complaining, it makes sense to fix it. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Allow void return type variance
On Mon, 4 Feb 2019 at 13:28, Wes wrote: > I know this too. I am often in touch with Levi and void variance is not > covered by his RFC > As a matter of fact, if you try to compile that PR void will behave exactly > like it does now > First of all, apologies as I needed a brush up on the difference between general variance and covariance. In fact, the RFC linked does not cover the variance of the void type. > My RFC targets 7.2 and 7.3 other than 7.4 > Secondly, I am nearly certain, but I would love to be proven wrong, that new features aren't backported to older PHP releases. So even then I don't think this will land in PHP 7.2/7.3 Now back to the proposal of the variance of void type. I'm not sure I see the point of it? Let me explain: if I define a method as void it means that it does stuff which doesn't/can't return a sensible value. Also, I am defining behavior and changing the return type, at least to me, is a change in behavior. Because a function/method which clearly is not intended to be used as a value can now under your proposal become one. Sure you can say that the return value may be only used by the child class but if I want to change my parent class to this child class I can't be sure that it will behave as before because *maybe* the child class needs the return value of this previously void method. Maybe I am just overthinking this however in my opinion if a return type needs to be changed from void to something you are trying to add behavior to a method which *probably* should go into its own method. Best regards George P. Banyard
Re: [PHP-DEV][RFC] Allow void return type variance
I know this too. I am often in touch with Levi and void variance is not covered by his RFC As a matter of fact, if you try to compile that PR void will behave exactly like it does now My RFC targets 7.2 and 7.3 other than 7.4 >
Re: [PHP-DEV][RFC] Allow void return type variance
I know this, I am talking about this RFC https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters Which has been voted and implementation is being worked on a GitHub PR: https://github.com/php/php-src/pull/3732 Your proposal doesn't bring anything new to the table that this RFC does. Moreover, your RFC targets the same PHP version as the covariant/contravariant RFC. So like said before the issue which your RFC tries to address is already being fixed. Also, there is no need to upgrade to PHPUnit 8 and if people want to there is a PHP_CS_FIXER sniff which can add void return types. Namely: void_return George P. Banyard On Mon, 4 Feb 2019 at 13:03, Wes wrote: > Covariance from no-type is already supported, since 7.0 > https://3v4l.org/I1hZs >
Re: [PHP-DEV][RFC] Allow void return type variance
Covariance from no-type is already supported, since 7.0 https://3v4l.org/I1hZs
Re: [PHP-DEV][RFC] Allow void return type variance
This is normal the Covariance/Contravariance is coming in PHP 7.4 not before. This RFC would also target PHP 7.4 so I don't see how this RFC would change the PHPUnit problem. George P. Banyard On Mon, 4 Feb 2019 at 12:54, Wes wrote: > Nope, it's not. https://3v4l.org/N4LNb It should've been fixed. > Indeed, many people expected it to work already. >
Re: [PHP-DEV][RFC] Allow void return type variance
Nope, it's not. https://3v4l.org/N4LNb It should've been fixed. Indeed, many people expected it to work already.
Re: [PHP-DEV][RFC] Allow void return type variance
Isn't this "fixed" with the Covariance/Contravariance RFC which has been
voted recently
George P. Banyard
On Mon, 4 Feb 2019 at 08:58, Wes wrote:
> Hi!
>
> PHPUnit 8 changed e.g. ` function setUp(){}` to ` function setUp():
> void{} ` and a lot of people did not like being forced to do the same on
> their `setUp()`.
>
> The issue is not PHPUnit adding `void`, but PHP forcing `void` even when
> it's not necessary. If PHPUnit wants to use void but inheritors don't want
> to, it should just be possible.
>
> "probably a bad idea" is opinionated, in reality there is no provable
> reason to disallow it, from a pure type-theory standpoint.
>
Re: [PHP-DEV][RFC] Allow void return type variance
Hi!
PHPUnit 8 changed e.g. ` function setUp(){}` to ` function setUp():
void{} ` and a lot of people did not like being forced to do the same on
their `setUp()`.
The issue is not PHPUnit adding `void`, but PHP forcing `void` even when
it's not necessary. If PHPUnit wants to use void but inheritors don't want
to, it should just be possible.
"probably a bad idea" is opinionated, in reality there is no provable
reason to disallow it, from a pure type-theory standpoint.
Re: [PHP-DEV][RFC] Allow void return type variance
> Le 4 févr. 2019 à 04:22, Wes a écrit : > > Hello PHPeeps! > > Recent events convinced me to write this RFC :P > > Please have a read here https://wiki.php.net/rfc/allow-void-variance > > I am targeting all the supported PHP versions because this is mainly to > placate the discontent that arised by PHPUnit enforcing its users to use > void, so waiting 7.4 doesn't make much sense. > > FTR this is an improvement regardless of PHPUnit, and it's IMO a very > reasonable change. > > Thank you for your time. > > Wes The RFC says: “Changing from void to something else is very probably a bad idea, but PHP should not enforce void in subclasses just on that basis.” — If it is “very probably” a bad idea, why do people want to do that? What are the use cases? (Sorry, I’ve not followed the “recent events” you alludes to.) —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
