I think the consensus is not so far away. As far as I understand the rules, it is possible to vote yes and put up a new RFC to remove strict-declare after the voting ends?
Regards Thomas Andi Gutmans wrote on 06.02.2015 00:22: > I have to say I’m pretty disappointed at the opening of the vote. > We had a pretty good RFC (thank you) for weak type hinting which was aligned > with the spirit of PHP and everyone was able to rally around it. > This has now been morphed into something very hard to swallow and IMO having > such a declare(…) syntax will be ridiculed by the broader app dev community > until the end of time… But even that syntax aside (it’s only syntax after > all), I think we lost the ability to reach consensus on something so important > to everyone which we haven’t been able to come to agreement on for over 10 > years. Finally it was there, in reach and you made a 180 degree turn. > > I think it’d be so much easier for us to implement weak type hinting. Have > everyone rally around it. Be happy and then learn and see whether an > additional > mechanism is really necessary. We could even add an E_STRICT_TYPES > error_reporting flag to help folks “debug” their code if they so wish to > see if there are any hotspots in their code they may want to take a look at - > again not necessarily an error but maybe a debugging tool. > > But net, net - why not just implement the thing everyone can agree on. Have > something really good in the spirit of the PHP Language for PHP 7 and learn > how > people leverage that… The reality is that for the majority of the Web > community “1” coming in from HTTP should be accepted as a 1. Period. > > I voted “no” but I will vote “yes” for the competing RFC which is 80% > of your RFC. Why are we not given that option?????? > > Andi > > >> On Feb 5, 2015, at 12:14 PM, Andrea Faulds <a...@ajf.me> wrote: >> >> Good evening, >> >> At long last, I’m going to put the RFC to a vote. It’s been long enough - >> I don’t think there needs to be, or will be, much further discussion. >> >> I’d like to make sure that everyone voting understands the RFC fully. Please >> read the RFC in full: the details are important. And if anyone has any >> questions or uncertainties, please ask them before voting. I am very happy to >> answer them. >> >> I would urge everyone who wants type hints to vote for this RFC. It is not a >> perfect solution, but there can be no perfect solution to this issue. >> However, >> I think it is better than most of the alternatives suggested thus far - see >> the rationale section, and previous discussions. Crucially, this RFC would >> keep PHP a weakly-typed language, and not force either strict typing, nor >> weak >> typing, on anyone who does not want it. It would allow the addition of type >> hints to existing codebases. It would not create a situation where userland >> functions are strict yet internal functions are not, because the strict mode >> affects both. I’ve tested the implementation myself on my own code, and it >> worked well, providing benefits other proposals would not have given (see my >> previous post about my experiences). >> >> Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). >> In addition to the vote on the main RFC, there is also a vote on the type >> aliases issue, and a vote to reserve the type names for future RFCs’ sake if >> this RFC fails. >> >> The RFC can be found here, and it contains a voting widget: >> https://wiki.php.net/rfc/scalar_type_hints >> >> Thank you for your time. >> >> -- >> Andrea Faulds >> http://ajf.me/ >> >> >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
