Dear Internals,
I have moved the Return Types RFC1 into voting phase. A few changes
have happened since it was originally announced but have been covered
by discussion.
Return types are now invariant. This means a sub-type must declare the
same return type as its super-type's method when overriding it.
Aliases such as self and parent must resolve to the same type.
Also note that picking invariance now does not mean we can't support
covariance later. This decision was a trade-off of my time and the
projected timeline for PHP 7. I was not confident I could produce an
excellent design and implementation in time for PHP 7 if I chose
covariance instead.
There is no reflection support for return types; another RFC2 will
handle this.
Dmitry updated a sizeable chunk of the implementation3 to work on
much more recent master branch. Thanks, Dmitry. I have updated it to
work on the latest master version as of the time of this writing and
altered one or two things to bring it into line with the RFC.
The voting period will end during the evening of 2015-01-23 in UTC-7.
This period is around ten days, which I hope is enough time for
everyone to be able to vote.
Hi Levi,
It's nice to see this RFC in voting phase again so quickly :) I just have
one question. Since we had some changes in the implementation will the
previous votes be discarded?
2015-01-14 6:18 GMT-03:00 Levi Morrison levim@php.net:
Dear Internals,
I have moved the Return Types RFC1 into voting phase. A few changes
have happened since it was originally announced but have been covered
by discussion.Return types are now invariant. This means a sub-type must declare the
same return type as its super-type's method when overriding it.
Aliases such as self and parent must resolve to the same type.Also note that picking invariance now does not mean we can't support
covariance later. This decision was a trade-off of my time and the
projected timeline for PHP 7. I was not confident I could produce an
excellent design and implementation in time for PHP 7 if I chose
covariance instead.There is no reflection support for return types; another RFC2 will
handle this.Dmitry updated a sizeable chunk of the implementation3 to work on
much more recent master branch. Thanks, Dmitry. I have updated it to
work on the latest master version as of the time of this writing and
altered one or two things to bring it into line with the RFC.The voting period will end during the evening of 2015-01-23 in UTC-7.
This period is around ten days, which I hope is enough time for
everyone to be able to vote.
Hi Levi,
It's nice to see this RFC in voting phase again so quickly :) I just have
one question. Since we had some changes in the implementation will the
previous votes be discarded?2015-01-14 6:18 GMT-03:00 Levi Morrison levim@php.net:
Dear Internals,
I have moved the Return Types RFC1 into voting phase. A few changes
have happened since it was originally announced but have been covered
by discussion.Return types are now invariant. This means a sub-type must declare the
same return type as its super-type's method when overriding it.
Aliases such as self and parent must resolve to the same type.Also note that picking invariance now does not mean we can't support
covariance later. This decision was a trade-off of my time and the
projected timeline for PHP 7. I was not confident I could produce an
excellent design and implementation in time for PHP 7 if I chose
covariance instead.There is no reflection support for return types; another RFC2 will
handle this.Dmitry updated a sizeable chunk of the implementation3 to work on
much more recent master branch. Thanks, Dmitry. I have updated it to
work on the latest master version as of the time of this writing and
altered one or two things to bring it into line with the RFC.The voting period will end during the evening of 2015-01-23 in UTC-7.
This period is around ten days, which I hope is enough time for
everyone to be able to vote.
The previous votes were discarded, yes.
Hi Levi,
I read the RFC quickly and could not find closure syntax example.
function():array use ($var) {}
or
function() use ($var): array {}
which one will be the syntax? I suppose first one will be the syntax,
though.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Levi,
I read the RFC quickly and could not find closure syntax example.
function():array use ($var) {}
or
function() use ($var): array {}
which one will be the syntax? I suppose first one will be the syntax,
though.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
The tests have it after the use(): https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9
This was discussed in depth a couple of times in the related threads.
Simon Welsh
Admin of http://91carriage.com/ – Specialised SilverStripe hosting
Hi Simon and Levi,
The tests have it after the use():
https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9This was discussed in depth a couple of times in the related threads.
Thank you for the information. It should be in the RFC. IMHO.
I feels natural to have type spec after function parameter definition
rather than
after "use".
Anyway, I looked HACK/HHVM manual
http://docs.hhvm.com/manual/en/index.php
and couldn't find the syntax.
If it's the same, then it should be OK.
I'm just making sure before voting.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Simon and Levi,
The tests have it after the use():
https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9This was discussed in depth a couple of times in the related threads.
Thank you for the information. It should be in the RFC. IMHO.
I feels natural to have type spec after function parameter definition
rather than
after "use".
Please do not change the RFC during votes phase, or re start it.
If many of the voters feel like they were voted on something different
of what is being discussed here, it may be a good thing to restart it.
However I think we all understood it as it is described in this
thread. Let update it after the votes or for the docs.
Hi Pierre and Levi,
Hi Simon and Levi,
On Fri, Jan 16, 2015 at 4:53 PM, Simon J Welsh simon@welsh.co.nz
wrote:The tests have it after the use():
https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9
This was discussed in depth a couple of times in the related threads.
Thank you for the information. It should be in the RFC. IMHO.
I feels natural to have type spec after function parameter definition
rather than
after "use".Please do not change the RFC during votes phase, or re start it.
If many of the voters feel like they were voted on something different
of what is being discussed here, it may be a good thing to restart it.
However I think we all understood it as it is described in this
thread. Let update it after the votes or for the docs.
Sounds good to me.
Let's update the RFC after vote.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Pierre and Levi,
Hi Simon and Levi,
On Fri, Jan 16, 2015 at 4:53 PM, Simon J Welsh simon@welsh.co.nz
wrote:The tests have it after the use():
https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9
This was discussed in depth a couple of times in the related threads.
Thank you for the information. It should be in the RFC. IMHO.
I feels natural to have type spec after function parameter definition
rather than
after "use".Please do not change the RFC during votes phase, or re start it.
If many of the voters feel like they were voted on something different
of what is being discussed here, it may be a good thing to restart it.
However I think we all understood it as it is described in this
thread. Let update it after the votes or for the docs.Sounds good to me.
Let's update the RFC after vote.
According to the previous discussion the return type goes after the
use statement, and this is how it is implemented. There has not been
an unintentional mistake here.
If you disagree with that decision I am open to discussing it again.
Since it isn't actually mentioned in the RFC (which was an oversight,
I apologize) I'm not sure we'd have to revote on it. Anyone else have
an opinion on this?
Hi Pierre and Levi,
Hi Simon and Levi,
On Fri, Jan 16, 2015 at 4:53 PM, Simon J Welsh simon@welsh.co.nz
wrote:The tests have it after the use():
https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9
This was discussed in depth a couple of times in the related threads.
Thank you for the information. It should be in the RFC. IMHO.
I feels natural to have type spec after function parameter definition
rather than
after "use".Please do not change the RFC during votes phase, or re start it.
If many of the voters feel like they were voted on something different
of what is being discussed here, it may be a good thing to restart it.
However I think we all understood it as it is described in this
thread. Let update it after the votes or for the docs.Sounds good to me.
Let's update the RFC after vote.According to the previous discussion the return type goes after the
use statement, and this is how it is implemented. There has not been
an unintentional mistake here.If you disagree with that decision I am open to discussing it again.
Since it isn't actually mentioned in the RFC (which was an oversight,
I apologize) I'm not sure we'd have to revote on it. Anyone else have
an opinion on this?
Addint/editing it means a re vote.
I do not think it is necessary at is pretty clear, or I think it is.
At the very least, let wait after the vote ended, to see if complains
will be raised.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi Pierre and Levi,
Hi Simon and Levi,
On Fri, Jan 16, 2015 at 4:53 PM, Simon J Welsh simon@welsh.co.nz
wrote:The tests have it after the use():
https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9
This was discussed in depth a couple of times in the related threads.
Thank you for the information. It should be in the RFC. IMHO.
I feels natural to have type spec after function parameter definition
rather than
after "use".Please do not change the RFC during votes phase, or re start it.
If many of the voters feel like they were voted on something different
of what is being discussed here, it may be a good thing to restart it.
However I think we all understood it as it is described in this
thread. Let update it after the votes or for the docs.Sounds good to me.
Let's update the RFC after vote.According to the previous discussion the return type goes after the
use statement, and this is how it is implemented. There has not been
an unintentional mistake here.If you disagree with that decision I am open to discussing it again.
Since it isn't actually mentioned in the RFC (which was an oversight,
I apologize) I'm not sure we'd have to revote on it. Anyone else have
an opinion on this?Addint/editing it means a re vote.
I did not mean editing it during vote; I meant that since the RFC does
not actually address this point it isn't technically included in the
vote. This means that if it passes we could alter this behavior if
desired while still being true to the vote.
Hey Pierre,
Addint/editing it means a re vote.
I don’t think this is always true. For minor changes to the RFC text that provide clarifications and do not change the actual proposal, there’s no problem with editing during voting.
In this case, the position of the return type in the anonymous function syntax isn’t a new detail of the proposal, as it was already in the patch. Adding it to the RFC would just help clear things up.
Thanks.
--
Andrea Faulds
http://ajf.me/
Hey Pierre,
Addint/editing it means a re vote.
I don’t think this is always true. For minor changes to the RFC text that
provide clarifications and do not change the actual proposal, there’s no
problem with editing during voting.In this case, the position of the return type in the anonymous function
syntax isn’t a new detail of the proposal, as it was already in the patch.
Adding it to the RFC would just help clear things up.
If the RFC is not clear, it should not proposed to vote on in the 1st place.
There must be no edit during the vote phase. It has abused too often
already. Be ready or wait until you are.
Thanks.
--
Andrea Faulds
http://ajf.me/
I have moved the Return Types RFC[1] into voting phase. A few changes
have happened since it was originally announced but have been covered
by discussion.
Hi,
After discussing this RFC between members of AFUP, we are +1.
Once this is done, extending it to nullable types and scalar hints could
be interesting too -- if the corresponding RFCs pass, of course.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will
close in a few hours. I want to thank everyone who has voted so far,
and encourage anyone who has not yet voted to do so.
As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will
close in a few hours. I want to thank everyone who has voted so far,
and encourage anyone who has not yet voted to do so.
I have close the voting. It has passed with a vote of 47 to 3.
I will update the patch to the latest master and then ping Dmitry to
do a final pass before merging it into master.
Hi Levi,
Do you like me to make final check and merge your pull request?
We need it :)
Thanks. Dmitry.
As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will
close in a few hours. I want to thank everyone who has voted so far,
and encourage anyone who has not yet voted to do so.I have close the voting. It has passed with a vote of 47 to 3.
I will update the patch to the latest master and then ping Dmitry to
do a final pass before merging it into master.
Dmitry,
I updated the patch to latest master and (seem to have) fixed a memory
issue with it. However when I pushed it back up Travis had a lot of failing
return types tests. Could you (and anyone else willing) pull it and see if
you are getting failing tests for release and debug builds?
Cheers,
Levi Morrison
Hi Levi,
Do you like me to make final check and merge your pull request?
We need it :)Thanks. Dmitry.
As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will
close in a few hours. I want to thank everyone who has voted so far,
and encourage anyone who has not yet voted to do so.I have close the voting. It has passed with a vote of 47 to 3.
I will update the patch to the latest master and then ping Dmitry to
do a final pass before merging it into master.
No problem, I'll verify if (fix if necessary) and commit.
Thanks. Dmitry.
Dmitry,
I updated the patch to latest master and (seem to have) fixed a memory
issue with it. However when I pushed it back up Travis had a lot of failing
return types tests. Could you (and anyone else willing) pull it and see if
you are getting failing tests for release and debug builds?Cheers,
Levi Morrison
Hi Levi,
Do you like me to make final check and merge your pull request?
We need it :)Thanks. Dmitry.
As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will
close in a few hours. I want to thank everyone who has voted so far,
and encourage anyone who has not yet voted to do so.I have close the voting. It has passed with a vote of 47 to 3.
I will update the patch to the latest master and then ping Dmitry to
do a final pass before merging it into master.