Hello everyone,
I've been following the "Static type hints" discussion for a while now. Aside
from its content, which there are some strong sentiments about, there's also
another recurring pattern - the wish for voting options instead of just
"yes/no".
Along these lines I've created an RFC on one aspect of primitive type hinting
(whether parameters or return type), namely reserving the primitive type names:
https://wiki.php.net/rfc/reserve_primitives
I personally see the benefits this could have but also the BC break this would
introduce. Let me know whether it's worthwhile putting this up for discussion.
I'm happy to add, elaborate or remove options as a result of feedback before
doing so.
Timm
Hi Timm,
Hello everyone,
I've been following the "Static type hints" discussion for a while now.
Presumably you mean "scalar" not "static".
Aside
from its content, which there are some strong sentiments about, there's also
another recurring pattern - the wish for voting options instead of just
"yes/no".Along these lines I've created an RFC on one aspect of primitive type hinting
(whether parameters or return type), namely reserving the primitive type names:https://wiki.php.net/rfc/reserve_primitives
I personally see the benefits this could have but also the BC break this would
introduce. Let me know whether it's worthwhile putting this up for discussion.
I'm happy to add, elaborate or remove options as a result of feedback before
doing so.
I don't see the point of this: the Scalar Type Hints RFC already has a voting option on reserving the type names, and it is set to pass, so by the time your RFC could go to a vote, it would have been rendered redundant.
Thanks.
--
Andrea Faulds
http://ajf.me/
Hi,
I personally see the benefits this could have but also the BC break this
would
introduce.
[...]
I don't see the point of this: the Scalar Type Hints RFC already has a voting
option on reserving the type names, and it is set to pass, so by the time your
RFC could go to a vote, it would have been rendered redundant.
My point is to prevent adoption hurdles before PHP 7's release. PHP 5 was a
sad story in regard to this. PHP 7 shouldn't be; and doesn't have to: So far,
PHP 7 has stayed largely BC-break free, which is good for its adoption.
I believe more than just yes and no should be considered in this case, which
breaks existing code - not just in edge cases and in near-bug-scenarios.
Timm
Hi,
I personally see the benefits this could have but also the BC break this
would
introduce.
[...]
I don't see the point of this: the Scalar Type Hints RFC already has a voting
option on reserving the type names, and it is set to pass, so by the time your
RFC could go to a vote, it would have been rendered redundant.My point is to prevent adoption hurdles before PHP 7's release. PHP 5 was a
sad story in regard to this. PHP 7 shouldn't be; and doesn't have to: So far,
PHP 7 has stayed largely BC-break free, which is good for its adoption.
If this RFC would somehow pass, yes. However, you’re introducing a competing proposal at the “eleventh hour”, so to speak, which is terribly nice. Unless there’s a radical shift in how people vote on the Scalar Type Hints RFC, it won’t pass, anyway.
I believe more than just yes and no should be considered in this case, which
breaks existing code - not just in edge cases and in near-bug-scenarios.
This has been discussed extensively in the Scalar Type Hints RFC thread, but people have voted to reserve the type names anyway.
I appreciate your concerns, but introducing a competing RFC while its competitor is in voting is both poor sportsmanship, and quite probably futile.
Andrea Faulds
http://ajf.me/
If this RFC would somehow pass, yes. However, you’re introducing a competing proposal at the “eleventh hour”, so to speak, which is terribly nice. Unless there’s a radical shift in how people vote on the Scalar Type Hints RFC, it won’t pass, anyway.
Sorry, I meant “isn’t terribly nice”.
--
Andrea Faulds
http://ajf.me/
Hi Timm
2015-02-08 13:04 GMT+01:00 Timm Friebe php@thekid.de:
Hello everyone,
I've been following the "Static type hints" discussion for a while now. Aside
from its content, which there are some strong sentiments about, there's also
another recurring pattern - the wish for voting options instead of just
"yes/no".Along these lines I've created an RFC on one aspect of primitive type hinting
(whether parameters or return type), namely reserving the primitive type names:
You forgot to add 'real' to the list (its a float).
--
regards,
Kalle Sommer Nielsen
kalle@php.net