Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58275 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52825 invoked from network); 28 Feb 2012 20:30:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Feb 2012 20:30:02 -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:13602] helo=mxout.myoutlookonline.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 82/43-36673-9493D4F4 for ; Tue, 28 Feb 2012 15:30:02 -0500 Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5642F556307; Tue, 28 Feb 2012 15:29:58 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 54DB9555A00; Tue, 28 Feb 2012 15:29:05 -0500 (EST) Received: from MAILR001.mail.lan ([10.110.18.27]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 28 Feb 2012 15:28:50 -0500 To: Michael Morris , "internals@lists.php.net" Date: Tue, 28 Feb 2012 15:28:48 -0500 Thread-Topic: [PHP-DEV] Scalar type hinting Thread-Index: Acz2Lb1MURJzNviDSGut1zikYHiBugAJRfqA Message-ID: References: <1330357150.2159.30.camel@guybrush> <4F4C1324.2040905@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [PHP-DEV] Scalar type hinting From: johncrenshaw@priacta.com (John Crenshaw) Inline. Quoted portion edited extensively for brevity. > -----Original Message----- > From: Michael Morris [mailto:dmgx.michael@gmail.com]=20 > > $a =3D 123; > function foo ( int $i ) {} > foo($a); // OK > > foo("123"); // NOTICE, because "123" is a constant >=20 > $a =3D "456"; > foo($a); // OK, because conversion is lossless >=20 -1. Should be no notice in either of the last two cases. Raising the notice= when a constant is used is inconsistent and confusing. I also doubt that t= his sort of implementation is even possible without some pretty massive int= ernal changes. Not worth it IMO. > int $a =3D 123; // "type locked" to integer >=20 > $a =3D "456"; // E_NOTICE > > $a =3D "Hello World"; // E_NOTICE I'm very dubious on hinting variables. This would require storing additiona= l data with the variable, which (as far as I can see) would break binary co= mpatibility (same problem as taint). I don't see much of a use for this mos= t of the time, with the notable exception of member variables (sometimes ty= pe locking a class member would be really nice.) Also, there should be no notice in case 2 (same argument as before with fun= ctions) Notice on case 3 is fine >=20 > unset($a); > $a =3D "Hello World"; // OK, because of unset >=20 > int $a; // E_NOTICE, $a had a value which can't convert without loss of d= ata. This just seems silly to me. Trying to declare int $a after $a is already p= resent and set is a nonsense construct. I think E_RECOVERABLE_ERROR should = be raised on this and $a should be set to null regardless of convertibility= (the more likely intent and meaning of that line of code) in case the erro= r handler decides to continue execution. > scalar $a; -1, I don't think we need this any more than we need an explicit "mixed" ty= pe. Saying "this function needs a number or it can't work" is one thing. Th= ere is a sound logical foundation for that. A scalar could be anything thou= gh. You're still going to have to check types to decide what you really hav= e and alter code paths as appropriate. > And if we don't want to unset $a but rather restore $a to behaving like a > scalar, that is how it would be done. -1, same argument as int $a; when $a is already set. This is a nonsensical = construction. You are using a variable declaration like a typecast and reus= ing a variable. This is sloppy and confusing to reduce code in a badly stru= ctured edge case. If you really honestly must untype a local variable, you = can always do this instead: $tmp =3D $a; unset($a); $a =3D $tmp; BUT, if there is any reason why you would actually need to untype a variabl= e, then there are much bigger problems. This shouldn't be handled in the co= re language. > So, in closing this ramble, if I right a db library whose functions are d= atatyped > you might see more notices, but the code will work and notices are usuall= y suppressed > by default (yes, I know about the RFC to change that) If using types causes a large number of unnecessary notices that's a spec p= roblem. The core devs aren't going to accept that. John Crenshaw Priacta, Inc.