> -----Original Message----- > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara > Golemon > Sent: Tuesday, February 17, 2015 1:58 AM > To: franc...@php.net > Cc: Philip Sturgeon; Arvids Godjuks; Jefferson Gonzalez; Rowan Collins; > PHP > internals > Subject: Re: [PHP-DEV] Reviving scalar type hints > > On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre <franc...@php.net> > wrote: > > Once again, anyone can take over version 0.3, if it is so great. Why > > don't > you do it ? > > I will play the game, stop working on my proposal, and vote 'yes' again. > > But don't ask me to do it in your place. > > > If nobody else does it, I will. > > I think Andrea's 0.3 proposal was extremely well balanced, served > everyone's > needs whether they would admit it or not, and who's only failing > (subjectively > termed) was the use of declare(). I think > declare() is fine and not nearly as ugly as some have slandered it to be, > but > I'm willing to read the winds and modify it for v0.4. > > Straw poll: > 1) <?php strict;
I like this one best. Obviously it requires some extra definition (e.g. I assume it will only be possible at the first block, perhaps only as the first part of the file or such). That syntax poll aside, I had what I hope is some sort an enlightenment, and I think I know what will get me to cast my vote in favor of 'strict', as a true supporter. There's one very special conversion that's too common in PHP to dismiss (IMHO), and is also completely harmless in 99.999% of the cases, if not strictly 100%: string->int or string->float conversions, when the string looks *exactly* like a number. Given almost all of our inputs (from databases, forms, files, etc.) come in string form, that's by far the conversion that's going to give us the most trouble - and is most probably the use case that by far is going to result the largest amount of explicit casts to work around that problem. What if strict mode didn't just blindly check zval.type, but actually allowed for this one type of conversion to go through without a problem? No bool to int. No Apple to int. No "123 testing" to float. Just "32" to 32 and "37.7" to 37.7. Can the strict supporting camp consider that option? Judging by the examples brought up by proponents of v0.3, this type of conversion isn't their issue. It's the 'obviously wrong' conversions that bug them. As a secondary concern I'd put int to float conversions where no (meaningful) data is being lost, e.g. 37 -> 37.0, even though a tiny bit of accuracy is lost. Rejecting this particular conversion places us at being stricter than mostly all other languages. That said, it's a much less common conversion so I don't feel nearly as strongly about it as the string one. Last, regarding internal functions, I do agree with Rasmus and Drew. Again, judging by the examples brought up as a part of the discussion, it seems as if we gave ZPP developers a standard easy way of being a lot more picky about the types of values of particular arguments, and allowing them to do this selectively for those places that are very sensitive (e.g. curl_setopt()) would be a more suitable solution than just turning strict validation for all internal functions, which were built with very very different assumptions in mind. The biggest difference between internal functions and userland functions in the context of this RFC is that with userland functions, we're starting with a clean slate. There are no type hint definitions anywhere, developers can selectively add them as they see fit. With internal functions, we have type requirements EVERYWHERE already, but with semantics that didn't take strict typing into account at all and evolved for almost 20 years. Strict typing the way it is now would radically change these semantics overnight, and will make the adoption of strict a much bigger headache than it can be, as I believe Rasmus demonstrated. I think addressing these issues could get us a LOT closer to consensus and make a lot of those who voted 'no' on v0.3 vote yes on v0.4. Thanks for your consideration. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
