# I quit. - Thread: https://externals.io/message/82851 - Original archive: https://news-web.php.net/php.internals/82851 - Started by Daniel Lowrey on 2015-02-16T15:12:40+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #82851 — Daniel Lowrey — 2015-02-16T15:12:40+00:00 URL: https://externals.io/message/82851#82851 > The 0.1 RFC version was mentioned a lot as a good compromise by many > people and had major support. People keep saying this like it's a thing, but I and others are vehemently opposed to this as a solution. The only thing weak hints accomplishes is the illusion of safety without actually providing it. You can already perform lossy casts on your inputs. Weak hints, IMHO, is the worst available option and I know plenty of folks who agree with me. 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. I wish people would stop suggesting that there was universal support for weak hints. There wasn't, and I suspect this dialogue was only avoided because the proposal gave a good option to those in favor of strict hints. --- ## #82852 — Zeev Suraski — 2015-02-16T15:19:37+00:00 URL: https://externals.io/message/82851#82852 · In reply to: #82851 > -----Original Message----- > From: rdlowrey@gmail.com [mailto:rdlowrey@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. > > > […] > > 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 --- ## #82853 — Daniel Lowrey — 2015-02-16T15:26:57+00:00 URL: https://externals.io/message/82851#82853 · In reply to: #82852 > > > […] solutions > > […] > > 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. --- ## #82859 — Arvids Godjuks — 2015-02-16T16:00:41+00:00 URL: https://externals.io/message/82851#82859 · In reply to: #82853 2015-02-16 17:26 GMT+02:00 Daniel Lowrey : > > > […] > error > > […] > solutions > > […] > accept > > […] > characters > > […] > giving > > […] > > > 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. --- ## #82861 — Daniel Lowrey — 2015-02-16T16:06:09+00:00 URL: https://externals.io/message/82851#82861 · In reply to: #82859 On Mon, Feb 16, 2015 at 11:00 AM, Arvids Godjuks wrote: > This bickering already jeopardized the type hinting RFC's how many times? 3 as I recall? Zeev was kind enough to reach out privately prior to your message and we began exchanged mails trying to better understand each other's point of view. In any case, this is certainly the wrong thread for discussions of the technical merits of a specific proposal. Let's keep it on-topic :) --- ## #82873 — Sven Drieling — 2015-02-16T18:45:22+00:00 URL: https://externals.io/message/82851#82873 · In reply to: #82859 Am Mon, 16 Feb 2015 18:00:41 +0200 schrieb Arvids Godjuks : Hallo, > 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. Split a scalar typehints RFC in several smaller RFCs, problems, questions, discussions? - Should PHP support scalar type hints? - What are the advantages of the typehints for objects? - What are the advantages of strict/weak types? - Be aware of the type handling of internal functions: - float silently converted to int str_repeat ( string $input , int $multiplier ) echo str_repeat('a', 3.7); - ... - Validation of user submitted data in frameworks is already strict type checking - ... tschuess [|8:)