Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58317 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40024 invoked from network); 29 Feb 2012 01:54:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 01:54:06 -0000 Authentication-Results: pb1.pair.com smtp.mail=johncrenshaw@priacta.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=johncrenshaw@priacta.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.244 as permitted sender) X-PHP-List-Original-Sender: johncrenshaw@priacta.com X-Host-Fingerprint: 64.95.72.244 mxout.myoutlookonline.com Received: from [64.95.72.244] ([64.95.72.244:24412] helo=mxout.myoutlookonline.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F7/E5-36673-C358D4F4 for ; Tue, 28 Feb 2012 20:54:05 -0500 Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 36628553FC3; Tue, 28 Feb 2012 20:54:02 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 55FDB553FC4; Tue, 28 Feb 2012 20:54:01 -0500 (EST) Received: from MAILR001.mail.lan ([10.110.18.27]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Tue, 28 Feb 2012 20:54:01 -0500 To: Kris Craig CC: Rick WIdmer , "internals@lists.php.net" Date: Tue, 28 Feb 2012 20:53:56 -0500 Thread-Topic: [PHP-DEV] Scalar type hinting Thread-Index: Acz2gxNUM9B/i+hqRCCTUgqqyp2HhAAANrGg Message-ID: References: <1330357150.2159.30.camel@guybrush> <693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com> <4F4D5D44.5090307@developersdesk.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A633CF2D7C7BED41B41F1E64F25507B8069DC46D04MAILR001maill_" MIME-Version: 1.0 Subject: RE: [PHP-DEV] Scalar type hinting From: johncrenshaw@priacta.com (John Crenshaw) --_000_A633CF2D7C7BED41B41F1E64F25507B8069DC46D04MAILR001maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would personally be inclined towards something simpler like E_NOTICE or E= _WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we = should be consistent, and the consistency argument may make the difference. There may be a strong case for changing the error level on all type hints t= o something simpler (or new, like E_TYPE), but I think that might be better= to tackle that in a separate discussion. John Crenshaw Priacta, Inc. From: Kris Craig [mailto:kris.craig@gmail.com] Sent: Tuesday, February 28, 2012 8:40 PM To: John Crenshaw Cc: Rick WIdmer; internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting I wouldn't mind that, though I'm concerned that it may not be sellable beca= use some people on here have expressed a strong opinion that this shouldn't= throw anything more than a notice or a warning at most, something that I a= nd others strongly disagree with. The logical approach, to me at least, is= to follow the example of include() and require(); i.e. they're both identi= cal except that one throws a scary error while the other one is just a warn= ing. I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may ali= enate too many people for us to be able to get this through. Though it's p= ossible I might be overestimating that factor. --Kris On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw > wrote: > On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer >wrote: > > > On 2/28/2012 2:58 PM, Kris Craig wrote: > > > > strong int $a =3D "1"; // Converts to 1. May or may not throw an erro= r > > (I'm > >> still on the fence). > >> > > > > It this is an error, it is no longer PHP. > > > > @Rick Though I'm not sure I'd agree with the overly broad "it is no longe= r PHP" hyperbole, I think the basic point that it would be a significant de= parture from the current model has merit. So ok, you've convinced me. That example should not throw any errors. I'm officially no longer on the = fence with that. =3D) > > --Kris OK, if we're all on the same page there, I think this means that there is n= o significant difference between the "strong int" and "weak int" in your pr= oposal (the only remaining difference being the level of error raised when = it cannot be converted, which IMO is not substantial enough to deserve a ke= yword.) I'd prefer to just pick one error level to use (E_RECOVERABLE_ERROR= would be the most consistent) and keep everything simple. John Crenshaw Priacta, Inc. --_000_A633CF2D7C7BED41B41F1E64F25507B8069DC46D04MAILR001maill_--