Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82859 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70606 invoked from network); 16 Feb 2015 16:01:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Feb 2015 16:01:06 -0000 Authentication-Results: pb1.pair.com header.from=arvids.godjuks@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=arvids.godjuks@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.175 as permitted sender) X-PHP-List-Original-Sender: arvids.godjuks@gmail.com X-Host-Fingerprint: 209.85.214.175 mail-ob0-f175.google.com Received: from [209.85.214.175] ([209.85.214.175:64434] helo=mail-ob0-f175.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 69/35-36518-04412E45 for ; Mon, 16 Feb 2015 11:01:05 -0500 Received: by mail-ob0-f175.google.com with SMTP id va2so43611773obc.6 for ; Mon, 16 Feb 2015 08:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C3l/80smMPpdXcBH5mwUBxktXWYx/fh7cUUtTc7k30Q=; b=Rn5AtMPaFwxpVEzjs4JeuiDt4F/RqCDwF+1vKObTJkrk2Mfsy6CmN3qesakxoMPVJI EpOu0hCn3odCiJSuOmnN/u4YNgyl1n8+KGWQJVdmmEfTja7H8VKa7kvGA3/JrKxEhGjV jHo0EVPJimzGv+ggEh04UVE4GLtNp5nChmaCyUmc4mPJAgk/sR5+2wOtoh/xHIlXxro7 eHqeVePjn7CQEthK0QXsL7mA+r8cJnTIKdEeRyWSl9Siz1zae23jE5FwQdGsPvlUeQXI pgFBZK5067g2T914VYof7KKacFo5mNQJb3HTcvmH0HPID29ynk6QxMIy7qrxFOHBW+xo /77g== X-Received: by 10.60.59.97 with SMTP id y1mr7752016oeq.17.1424102462230; Mon, 16 Feb 2015 08:01:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.14.39 with HTTP; Mon, 16 Feb 2015 08:00:41 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Feb 2015 18:00:41 +0200 Message-ID: To: Daniel Lowrey Cc: Zeev Suraski , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=089e013d0958629762050f36b1be Subject: Re: [PHP-DEV] Re: I quit. From: arvids.godjuks@gmail.com (Arvids Godjuks) --089e013d0958629762050f36b1be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015-02-16 17:26 GMT+02:00 Daniel Lowrey : > On Mon, Feb 16, 2015 at 10:19 AM, Zeev Suraski wrote: > > > > > -----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. > > > > > > > The 0.1 RFC version was mentioned a lot as a good compromise by man= y > > > > 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=3D1420209410)= : > > > > "=E2=80=A0Non-numeric strings not accepted. Numeric strings with traili= ng > characters > > produce a notice." > > > > =E2=80=A0 applied to both int and float type hints in case of string in= puts. > > > > 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. --089e013d0958629762050f36b1be--