Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58804 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33988 invoked from network); 9 Mar 2012 03:08:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2012 03:08:42 -0000 Authentication-Results: pb1.pair.com header.from=johncrenshaw@priacta.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=johncrenshaw@priacta.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.241 as permitted sender) X-PHP-List-Original-Sender: johncrenshaw@priacta.com X-Host-Fingerprint: 64.95.72.241 mxout.myoutlookonline.com Received: from [64.95.72.241] ([64.95.72.241:21492] helo=mxout.myoutlookonline.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D5/54-10820-834795F4 for ; Thu, 08 Mar 2012 22:08:41 -0500 Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2397E8BEA29; Thu, 8 Mar 2012 22:08:38 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id A91C78BE7F3; Thu, 8 Mar 2012 22:08:37 -0500 (EST) Received: from MAILR001.mail.lan ([10.110.18.27]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Thu, 8 Mar 2012 22:08:23 -0500 To: Adam Jon Richardson CC: "internals@lists.php.net" Date: Thu, 8 Mar 2012 22:08:24 -0500 Thread-Topic: [PHP-DEV] Scalar Type Hinting Thread-Index: Acz9nITCTmglQuwfSGChx3oV7gEapQAAIaMw Message-ID: References: <52.38.15021.3A1E65F4@pb1.pair.com> <4F570EBB.6030103@sugarcrm.com> <60744d7ea642fe03c7110502a3f4276a@mohiva.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [PHP-DEV] Scalar Type Hinting From: johncrenshaw@priacta.com (John Crenshaw) From: Adam Jon Richardson [mailto:adamjonr@gmail.com]=20 > I don't think it's fair to say that casting is too forgiving OR > that current sentiment is settling around behavior similar to the > internal zend_parse_parameters.=A0This is a complex issue, and there > are many core developers who have been focusing on other things > besides this discussion. Their silence likely does not demonstrate > sentiment of approval for anything at this point. This particular > subject has much history on the PHP mailing list, and the opinions > are far ranging. More importantly, this general subject has much > history in all of the programming languages that are dynamically > typed. Sorry, you misunderstood. What I meant was *not* that core developers had b= ought into this (whether that will happen is unknown.) I meant that the dis= cussion in this thread among the most active participants appeared to shift= hard this direction as soon as it was proposed (can't remember who by.) Ta= ken in the context of everything else it was a good foundation that solved = a number of problems all at once. > Let's look at the examples you gave: > > (function(int){})('1'); // no error, function gets (int)1 > (function(int){})('123xyz'); // E_NOTICE, function gets (int)123 > (function(int){})('xyz'); // E_WARNING, function gets (int)0 > > I'm wondering where you would be getting the values '123xyz' and 'xyz' fr= om at runtime... It doesn't so much matter where it comes from or why. The spec has to defin= e how such inputs are handled (the behavior can't be undefined). E_NOTICE a= nd E_WARNING matches a behavior that we know has already been considered ac= ceptable in the core (I.E. this is the behavior of substr()). > Joe Armstrong, creator of the dynamically typed Erlang language, > advocates performing checks on the datatypes at the points in the > application that receive input, but not within the internal functions. > It's an interesting view, and he seems to have had success building > robust, stable software using this approach. I tend to agree, but this sort of argument hasn't held much sway in the pas= t on the typing issue in PHP so in terms of designing a viable RFC that can= pass a vote I don't see that it matters much what we think here. > Now, I'm not saying that this should be PHP's approach. I recently > presented the idea of having a scalar type (with aliases) because > this could identify problems the first time a PHP file is parsed > rather than at runtime. However, I do bring up Joe Armstrong's > approach to temper the belief that casting or something less is > "too forgiving." At least for me, script inputs are far less important than other stuff; for= example, generating good errors after a refactoring mistake. Allowing ever= ything to pass through without errors solves the documentation issue, but b= asically nothing else. > I very much enjoyed seeing someone as skilled as Anthony crank out > a quick proof-of-concept (I'd still be sifting through Zend's > internals trying to get out of my Objective-C mode of thinking.) Yes, huge thanks for Anthony's contributions here. > I just hope that we look at all options (including doing nothing), > consider the research already done on dynamic type systems, and look > to examples in other programming languages that can give us insights > into what works well and what doesn't. > > Adam Agreed. I've been advocating the collection and organization of information= from prior discussions for a while. If there is good stuff to learn from d= iscussions in similar languages we should look over that too. The primary b= arrier I see here is time. Looking over all this will take a lot of work. John Crenshaw Priacta, Inc.