2015-02-16 17:26 GMT+02:00 Daniel Lowrey <rdlow...@php.net>: > On Mon, Feb 16, 2015 at 10:19 AM, Zeev Suraski <z...@zend.com> wrote: > > > > > -----Original Message----- > > > From: rdlow...@gmail.com [mailto:rdlow...@gmail.com] On Behalf Of > > > Daniel Lowrey > > > Sent: Monday, February 16, 2015 5:13 PM > > > To: internals@lists.php.net > > > Subject: [PHP-DEV] Re: I quit. > > > > > > > The 0.1 RFC version was mentioned a lot as a good compromise by many > > > > people and had major support. > > > > > > Any proposal to the scalar hints problem that doesn't definitively > error > > > out in > > > the `(int) "apple"` case is a non-starter for me; I believe such > solutions > > > are > > > disingenuous at best and dangerous at worst. > > > > Weak type hints the way Andrea proposed them in v0.1 actually did not > accept > > "Apple" as an int (wiki.php.net/rfc/scalar_type_hints?rev=1420209410): > > > > "†Non-numeric strings not accepted. Numeric strings with trailing > characters > > produce a notice." > > > > † applied to both int and float type hints in case of string inputs. > > > > Judging by both this and Anthony's message from a couple of days ago > giving > > the same Apple example, perhaps v0.1 wasn't clearly understood. > > > > Zeev > > > Perhaps I should've been more explicit: "Numeric strings with trailing > characters produce a notice." is also unacceptable. > > curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true); > > > ^ It's my own personal opinion, but as I said before and still believe, > allowing such behavior is disingenuous at best and dangerous at worst. >
This bickering already jeopardized the type hinting RFC's how many times? 3 as I recall? Right now we need a breakthrough event - get type hints into the language at all. The most sensible thing to do it is to add basic type hints that work like the current conversion rules, maybe add some notices/warnings for some cases. Or adjust the conversion rules themselves in line with the new type hints. Whatever type of typehints I like personally better does not matter, what matters is what is fitting the language and is reasonable. And what leaves improvement avenues for the future. It is better to make smaller changes, than making a god type feature and then realizing that, if something got messed up badly, you can't fix it, because it is already a BC issue. I always liked the incremental nature of PHP maturing and adding features. Just stick with it, do the typehints in increments. Be patient. It's not like next release after 7.0 is going to take a years like before, we have releases every year now.
