Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58147 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86936 invoked from network); 27 Feb 2012 16:16:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 16:16:52 -0000 Authentication-Results: pb1.pair.com header.from=dmgx.michael@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dmgx.michael@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender) X-PHP-List-Original-Sender: dmgx.michael@gmail.com X-Host-Fingerprint: 209.85.212.170 mail-wi0-f170.google.com Received: from [209.85.212.170] ([209.85.212.170:56424] helo=mail-wi0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6F/7B-40985-37CAB4F4 for ; Mon, 27 Feb 2012 11:16:52 -0500 Received: by wibhm4 with SMTP id hm4so3361325wib.29 for ; Mon, 27 Feb 2012 08:16:49 -0800 (PST) Received-SPF: pass (google.com: domain of dmgx.michael@gmail.com designates 10.180.8.164 as permitted sender) client-ip=10.180.8.164; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dmgx.michael@gmail.com designates 10.180.8.164 as permitted sender) smtp.mail=dmgx.michael@gmail.com; dkim=pass header.i=dmgx.michael@gmail.com Received: from mr.google.com ([10.180.8.164]) by 10.180.8.164 with SMTP id s4mr29641793wia.6.1330359409206 (num_hops = 1); Mon, 27 Feb 2012 08:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=lVtva4VOozvBGGwop7vLopyLLcDtg+Ss+G0528yUxhU=; b=aWkwZGcYGmAtTJf/rCIhNj0nYTjNdz9U0YQa1p1Tmx4G6DymaO+1ZYTr0Bz2owrK0Q D6hRk6Js0ELK/qV1z6Gn7UTbkKUyt792Wt3XktWC9MHG3fnEbPmQuKXBmRPnsXjAFsdk 5ZpPXD6OwhF4axyz73QhGwPgM5VY8Zh0dVDXU= MIME-Version: 1.0 Received: by 10.180.8.164 with SMTP id s4mr23489837wia.6.1330359409026; Mon, 27 Feb 2012 08:16:49 -0800 (PST) Received: by 10.216.30.149 with HTTP; Mon, 27 Feb 2012 08:16:48 -0800 (PST) In-Reply-To: <1330357150.2159.30.camel@guybrush> References: <1330357150.2159.30.camel@guybrush> Date: Mon, 27 Feb 2012 11:16:48 -0500 Message-ID: To: "internals@lists.php.net" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Scalar type hinting From: dmgx.michael@gmail.com (Michael Morris) So the official response is "get lost"? I don't know about the internals implications. But from an external API standpoint I see no problem in allowing programmers who want to strictly enforce a variable's datatype to do so. Legacy code would not be affected unless it was trying to use the new reserved word "strict" 2012/2/27 Johannes Schl=FCter : > Hi, > > PHP is no strickt-typed language. Changing this is a massive change, if > you want to go there: There are plenty of other languages. > > If you want this to be an optional feature: > a) It's not optional (one has to maintain code written by others, uses > libraries, frameworks, ...) > b) It causes a hell lot of trouble with copy-on-write. going from > fixed-typed to non-fixed-typed variables (in a funciton call or > assignment or such) will always have to cause a copy. This will hurt the > performance in hardly predictable ways. > > johannes > > On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote: >> What I've wanted for awhile, but don't know what the implementation >> problems would be, is to allow for two new variable types to solve >> this problem - Strict and tolerant variables. =A0Both of these must be >> declared formally (otherwise PHP assumes scalar) and the datatype must >> be included. The syntax >> >> // A tolerant variable. >> integer $a =3D 3; >> >> // A strict variable >> strict integer $b =3D 2; >> >> Tolerant variables silently cast values to their declared datatype. >> Maybe they should raise E_NOTICE? >> Strict variables refuse to be assigned a value with an incorrect >> datatype. =A0Raise E_WARNING? >> >> A strict function would have the current behavior of kicking a warning >> when the type hinting fails. =A0Otherwise, functions should be tolerant >> - >> >> function foo ( integer $a, string $b, $c ) {} >> >> strict function foo ( integer $a, $string $b, $c ) {} >> >> A function parameter without a datatype would be ignored. >> >> This does open the door to function overloading, but the engine >> problems of this are well documented and have been discussed. =A0Still, >> I don't think it's a bad thing to have a syntax that allows for method >> overloading in the future. >> >> On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig wrot= e: >> > I'll try to find some time tonight to create that for ya. >> > >> > Once this discussion comes together a little bit more and we have at l= east >> > a vague-ish idea what direction we're moving in, I'll also go ahead an= d >> > create an RFC as well so we have a conceptual product to build on. >> > >> > --Kris >> > >> > >> > On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal w= rote: >> > >> >> Hi, >> >> >> >> I create a new thread to discuss about Scalar type hinting. >> >> >> >> Following the John Crenshaw proposed terminology: >> >> > - "Strict Typing" means the super strict old C style typing that ha= s >> >> been proven to be ridiculous in this environment because of the obvio= us >> >> problems inherent in the fact that almost every input is a string. >> >> > - "Weak Typing" means types in the same sense that the PHP document= ation >> >> uses types (for example, the docs indicate substr(string, integer), a= nd >> >> substr(12345, "2") =3D=3D "345".) >> >> > - "No Scalar Typing" should be used to indicate the current system >> >> (where there is no provision for hinting at scalar types.) >> >> >> >> Previous weak typing proposal could be found here : >> >> https://wiki.php.net/rfc/typechecking >> >> >> >> I have no rights to edit the wiki and make a summary of previous >> >> arguments, so if someone could create it... >> >> >> >> >> >> -- >> >> Samuel DEAL >> >> samuel.deal@gmail.com >> >> >> >> >> > >