Re: [RFC] Allow void return type variance
| From: | Girgias | Date: | Mon, 04 Feb 2019 13:10:17 +0000 |
| Subject: | Re: [RFC] Allow void return type variance | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-104118@lists.php.net to get a copy of this message | ||
On Mon, 4 Feb 2019 at 13:28, Wes <netmo.php@gmail.com> 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