Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58142 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79388 invoked from network); 27 Feb 2012 15:59:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 15:59:26 -0000 Authentication-Results: pb1.pair.com header.from=arvids.godjuks@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=arvids.godjuks@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: arvids.godjuks@gmail.com X-Host-Fingerprint: 209.85.212.170 mail-wi0-f170.google.com Received: from [209.85.212.170] ([209.85.212.170:65298] helo=mail-wi0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 69/C9-40985-C58AB4F4 for ; Mon, 27 Feb 2012 10:59:25 -0500 Received: by wibhm4 with SMTP id hm4so3346985wib.29 for ; Mon, 27 Feb 2012 07:59:22 -0800 (PST) Received-SPF: pass (google.com: domain of arvids.godjuks@gmail.com designates 10.180.95.105 as permitted sender) client-ip=10.180.95.105; Authentication-Results: mr.google.com; spf=pass (google.com: domain of arvids.godjuks@gmail.com designates 10.180.95.105 as permitted sender) smtp.mail=arvids.godjuks@gmail.com; dkim=pass header.i=arvids.godjuks@gmail.com Received: from mr.google.com ([10.180.95.105]) by 10.180.95.105 with SMTP id dj9mr29430172wib.18.1330358362264 (num_hops = 1); Mon, 27 Feb 2012 07:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mQWfjdU/zqrZkSkV0TFqW2u/PycG28h2pwLax48yUG4=; b=RE2YIS4/ES2R4A9vAUj3W1kIxyBVCrZuyGoGaJJMmsJthrJHOGyRUsNuuANOIswzm/ ZSfITCLqLS6+YSbYMrRV5EOsdROXy/W1QoAeVP92aCQw9G7/SbalAqucwgrk+RHzOH1M SbK8sWdIZR6CPtJsdYy7Ksgy2swGTaOlvXcwc= Received: by 10.180.95.105 with SMTP id dj9mr23332431wib.18.1330358362108; Mon, 27 Feb 2012 07:59:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.117.1 with HTTP; Mon, 27 Feb 2012 07:59:02 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> Date: Mon, 27 Feb 2012 17:59:02 +0200 Message-ID: To: Paul Dragoonis Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= , Michael Morris , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Scalar type hinting From: arvids.godjuks@gmail.com (Arvids Godjuks) But what about optional weak (auto-convert) type hints? They should make life if not easier, definitively a little richer when writing API's and internal stuff, where some additional strictness and warnings generated make sense. And it definitively makes IDE's more happy and easier to generate PHPDoc blocks, not to mention Reflection stuff can be added and find it's uses pretty fast. I see it as anonymous functions - you can definitively live without them, but they are wonderful and made some functionality better (for example Yii Framework used eval for many things and with PHP 5.3 we just started to use anonymous functions instead - the support was build in before the 5.3 even started) - same I see happening here in the future. But yes, any major work that changes things a lot will just make a mess and many BC issues. 2012/2/27 Paul Dragoonis : > 2012/2/27 Johannes Schl=C3=BCter > >> 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 >> > > Big +1 from me. Thanks for the post Johannes! > > It makes sense to have a type hint for the different type of data > structures. > 1) array > 2) object ( class name for OOP ). > > The scalar values (int, string, double) are type-less, flexible and shoul= d > remain that way. If you want strict typehinting then move to another > language. > > >> >> 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. =C2=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. =C2=A0Raise E_WARNING? >> > >> > A strict function would have the current behavior of kicking a warning >> > when the type hinting fails. =C2=A0Otherwise, functions should be tole= rant >> > - >> > >> > 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. =C2=A0St= ill, >> > 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 >> wrote: >> > > 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 >> least >> > > a vague-ish idea what direction we're moving in, I'll also go ahead = and >> > > 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 >> wrote: >> > > >> > >> 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 = has >> > >> been proven to be ridiculous in this environment because of the >> obvious >> > >> problems inherent in the fact that almost every input is a string. >> > >> > - "Weak Typing" means types in the same sense that the PHP >> documentation >> > >> uses types (for example, the docs indicate substr(string, integer), >> and >> > >> substr(12345, "2") =3D=3D "345".) >> > >> > - "No Scalar Typing" should be used to indicate the current syste= m >> > >> (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 >> > >> >> > >> >> > >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>