Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58304 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1166 invoked from network); 28 Feb 2012 23:03:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Feb 2012 23:03:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 209.85.220.170 mail-vx0-f170.google.com Received: from [209.85.220.170] ([209.85.220.170:65517] helo=mail-vx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 78/ED-36673-25D5D4F4 for ; Tue, 28 Feb 2012 18:03:46 -0500 Received: by vcbfo14 with SMTP id fo14so2255723vcb.29 for ; Tue, 28 Feb 2012 15:03:43 -0800 (PST) Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.52.71.166 as permitted sender) client-ip=10.52.71.166; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kris.craig@gmail.com designates 10.52.71.166 as permitted sender) smtp.mail=kris.craig@gmail.com; dkim=pass header.i=kris.craig@gmail.com Received: from mr.google.com ([10.52.71.166]) by 10.52.71.166 with SMTP id w6mr15452989vdu.20.1330470223971 (num_hops = 1); Tue, 28 Feb 2012 15:03:43 -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 :cc:content-type; bh=3UoXlIuDAFlB9TGsRxo0OWrJ1PFct40tp9DDvbnI4Ho=; b=O+vdo7SVvw3C0kHqMk+v4LJKPmcyPM6LhyrRZ5KHX1ZyN3L2wIJORQsVo80k3Bpylm nHHsjw+aDJpyO2DswZh4vnX8pm6hPCzDNztLqUSqMGesXR8XlM0rXPDiAQ5WuqX1GuUl Av80Q3Dz6k11By3H9W1ukNT+zYsLXYu812MUs= MIME-Version: 1.0 Received: by 10.52.71.166 with SMTP id w6mr12806764vdu.20.1330470223907; Tue, 28 Feb 2012 15:03:43 -0800 (PST) Received: by 10.52.91.5 with HTTP; Tue, 28 Feb 2012 15:03:43 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> <4F4C1324.2040905@gmail.com> Date: Tue, 28 Feb 2012 15:03:43 -0800 Message-ID: To: Arvids Godjuks Cc: Simon Schick , Michael Morris , internals@lists.php.net Content-Type: multipart/alternative; boundary=20cf3071ce6c148a0f04ba0e3d9b Subject: Re: [PHP-DEV] Scalar type hinting From: kris.craig@gmail.com (Kris Craig) --20cf3071ce6c148a0f04ba0e3d9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One thing I've been noticing, and I think we should be careful of in this discussion, is making broad "....and this is what most people want" statements. I've heard a number of people make some variation of that claim now to support at-times radically different approaches. So, unless most people want *everything*, including the things that directly contradict one another, then I think it's safe to say that some of us are giving in to the temptation to use hyperbole. It's understandable and I've probably done it myself on more than one occasion. But I think we have to be careful not to make such claims unless we actually have data to back them up. None of us can *credibly* state that one approach or another is supported by "most people" or "most developers," etc. Unless somebody can product a scientific poll on the subject, there is no clear majority consensus on this. If there was, we wouldn't still be having this discussion after so many years. So please, let's all be careful not to make baseless claims about "most (insert plural noun here)" supporting one idea or another. All it does is add needless confusion and clutter to an already complex issue. --Kris On Tue, Feb 28, 2012 at 2:56 PM, Arvids Godjuks w= rote: > Hi, Simon. > > Actually I also advocated for notices/warnings on conversion with data > loss. > What just has to be done - the rule table when notices/warnings are throw= n. > > What I have in mind is no variable type hinting at all. What I want to > see is function/method type hinting. > And, because the zval actually has type in it, you actually already > weakly type hint the variable anyway: > > $a =3D 1; > echo gettype($a); // integer > > $a =3D (int)"1"; > echo gettype($a); // integer > > $a =3D (string)1; > echo gettype($a); // string > > And so on. This part is in the language, just has different syntax. > > So no-no-no from me on this: > int $a =3D 1; > int $a =3D "1"; > > It just duplicates the functionality. And I don't like the strict int > $a =3D 1; I have already explained why it's not a good idea from the > technical standpoint. > > So what I want is this: > > function int test(int $a, int $b) > { > return $a * $b; > } > test(1, 2); // 2; > test("1", 2); // 2 > test("1aaa", 2); // E_NOTICE or E_TYPE and result 2 > test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type hin= t > now. > > It's really what the most people want. Simple, easy to pick up (object > and array already have this) and is just optional. > > I purpose to deal with this and when it works and is released to the > wild then see if more strictness even is needed. I think this simple > weak type hinted functionality will suffice. > > ---------- Forwarded message ---------- > From: Simon Schick > Date: 2012/2/28 > Subject: Re: [PHP-DEV] Scalar type hinting > To: Arvids Godjuks > =D0=9A=D0=BE=D0=BF=D0=B8=D1=8F: Michael Morris , = internals@lists.php.net > > > Hi, Arvids > > I do understand your arguments ... > > For me personally it's mostly to separate between string and numbers. > A string to number transformation is most-likely not without loosing > something ... This is most likely the reason why I want to have a > E_STRICT or E_NOTICE if something like that happens. Same appears to a > transformation of a number to Boolean. > I don't really care how variables are handled in the very inner part > of the php-core as long as it's effective ;) > > As you're talking about serialization ... that's right ... If you're > serializing an array containing strict variables would require a > change. > Here you'll have a big downwards-compatibility-break ... > > We can do this discussion endless ... but I think you got the point > why I want something like this. > Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a > function and marking it as warning if I try to put in an integer > whereas the documentation says that this function expects a string (or > an error if it should be an object or array). > > Bye > Simon > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --20cf3071ce6c148a0f04ba0e3d9b--