Hi, > On 8 Feb 2015, at 13:32, Timm Friebe <p...@thekid.de> wrote: > >>> 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
