Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75606 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45933 invoked from network); 16 Jul 2014 21:17:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Jul 2014 21:17:25 -0000 Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.216 imap10-3.ox.privateemail.com Received: from [192.64.116.216] ([192.64.116.216:57484] helo=imap10-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/B1-37298-4EBE6C35 for ; Wed, 16 Jul 2014 17:17:24 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id EB97F2400E4; Wed, 16 Jul 2014 17:17:20 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap10.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap10.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id p9ZBVdRE8gWS; Wed, 16 Jul 2014 17:17:20 -0400 (EDT) Received: from [192.168.0.15] (unknown [90.210.122.167]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id C64672400C2; Wed, 16 Jul 2014 17:17:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) In-Reply-To: <221d3e5c1be1ee2277e05027912762db@mail.gmail.com> Date: Wed, 16 Jul 2014 22:17:13 +0100 Cc: Stas Malyshev , Andrey Andreev , Rowan Collins , internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me> <53C460DF.5040304@sugarcrm.com> <53C53A96.2040303@gmail.com> <53C55342.1010207@sugarcrm.com> <53C563B3.6060905@gmail.com> <54536191-1B92-4933-973F-0C8289D13A4C@ajf.me> <00d12255efc53466245b21a83ff7d474@mail.gmail.com> <1CE2ACC0-D6CA-407B-99C7-4914311B733E@ajf.me> <53C6CFB7.8090908@sugarcrm.com> <118BB3D7-BE52-44AB-BD0E-942830D44A2A@ajf.me> <9B7B8559-61FE-493D-BAEE-53E8C84D5E91@ajf.me> <221d3e5c1be1ee2277e05027912762db@mail.gmail.com> To: Zeev Suraski X-Mailer: Apple Mail (2.1878.6) Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) From: ajf@ajf.me (Andrea Faulds) On 16 Jul 2014, at 22:10, Zeev Suraski wrote: > Stricter typing does not belong in PHP. If it did, we'd have it in > internal functions, implicit casting and the rest of the language in > general. We don=92t. This proposal isn=92t that much stricter than zpp, aside from booleans I = suppose. It=92s not like we allow literally anything as function = arguments for internal functions. > And I insist that much like you said people can catch = E_RECOVERABLE_ERROR > and turn ignore it, they can do the same with E_CASE - except now they > won't *have* to learn about this new behavior unless they explicitly = want > to. While you think it may not be strict enough for some people, and = I > think it'd be too strict for others - the consistency argument should = make > the decision between the two obvious. E_CAST is problematic. Having something we encourage some people to make = an error and some people not to means that in some cases your library = works fine and rosy in other people=92s environments and sometimes it = crashes your app. This is *not good*. We must not encourage people to = make things errors conditionally. It=92s either an error or not. I=92d = veer towards error. Also, it=92s worth pointing out that people will have to learn the new = behaviour anyway; no matter how we do scalar type hints, we don=92t = currently have them, and once implemented, everyone will have to get = used to their existence (and probably the fact they will raise = E_RECOVERABLE_ERROR). > Also, I tend to agree with Stas that we can consider to do > E_RECOVERABLE_ERROR on the obviously 'bogus' conversions - like array = or > object to int. But E_RECOVERABLE_ERROR on simple data loss is = radically > inconsistent with the rest of PHP. >=20 > Sorry, I introduced hinting into PHP; I intentionally did not add = typing > for scalars as it goes against the fundamentals of the language, and I > fought this off back in 2008, 2010 and mildly also in 2012. Call me > persistent :) >=20 > FWIW, I think the distance between where you and I stand is not that = big - > and if we go in the direction of E_CAST for data loss across the board > (any implicit casts, not just in type hints), and E_RECOVERABLE_ERROR = for > completely broken type conversions - this is a big win for PHP, beyond > just type hints. I really don=92t like E_CAST for the reasons mentioned above. If it=92s = a glorified E_NOTICE, it=92s pointless, if it=92s a glorified = E_RECOVERABLE_ERROR, you gain nothing, and if it=92s an error in some = environments and not in others, we=92ve just completely broken our = ecosystem. -- Andrea Faulds http://ajf.me/