Re: Scalar type hinting

@Richard I think you made a very good point. Should we treat a float => int mismatch the same as we would a string => int mismatch, or should the former fail more gracefully? I can see good arguments for both. --Kris On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch <ceo@l-i-e.com> wrote: > On Tue, February 28, 2012 5:17 pm, Kris Craig wrote: > > Some cases I would find interesting to be explained: > > (using 'streak' for strong and/or weak, feel free to separate the two) > > streak int $i = 123.456; //Common idiom for floor() > streak int $i = "123.456"; //In contrast to previous > streak int $i = "1 "; //value="1 " is ridiculously common HTML > > It's all well and good to say that any loss of data is "bad" and to > raise some E_* for it, but there are some idioms so common that feel > "wrong" as I consider them... > > If everyone "for" the new type hinting/forcing can reach consensus on > these sorts of cases, it would help clarify any RFCs a bit, I think > > wrt E_RECOVERABLE_ERROR vs E_WARNING > > If current type hinting raises E_RECOVERABLE_ERROR, I have no > objection to following that lead, with the explicit caveat that a > change to the existing type-hinting to E_WARNING, as unlikely as that > seems, would pull the new "streak" with it. > > I don't even object to using E_ERROR for the "strong" variant, if that > passes review, really, since "strong" is, errr, strong. :-) > > Anybody who doesn't like the E_* can re-define them in a custom error > handler anyway, though allowing PHP to continue after E_ERROR is like > playing russian roulette... > > -- > brain cancer update: > http://richardlynch.blogspot.com/search/label/brain%20tumor > Donate: > > > https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >