> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Monday, February 23, 2015 2:25 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Ze'ev,
It's Zeev, thanks :) > Because strict types makes that an error case. So I can then tell the user > to > fix it. Once they do (via cast, logic change, etc), I know the types of > every > variable the entire way through. So I can generate native code for both > calls > without using variants. I think we are indeed getting somewhere, I hope. If I understand correctly, effectively the flow you're talking about in your example is this: 1. The developers tries to run the program. 2. It fails because the static analyzer detects float being fed to an int. 3. The user changes the code to convert the input to int. 4. You can now optimize the whole flow better, since you know for a fact it's an int. Did I describe that correctly? > With strict typing at the foo() call site, it tells you that $input has to > be an int > or float (respectively between the snippets). I'm not following. Are you saying that because foo() expects an int or float respectively, $input has to be int or float? What if $input is really a string? Or a MySQL connection? Or are you saying that there was a strict type hint in the function that contains the call to foo(), so we know it's an int/float respectively? If so, how would it be any different with a coercive type hint? > I hope that makes my point a little clearer, It actually does, I hope. I think we are getting somewhere, but we're not quite there yet. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
