Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58783 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40599 invoked from network); 8 Mar 2012 13:18:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Mar 2012 13:18:20 -0000 Authentication-Results: pb1.pair.com smtp.mail=arvids.godjuks@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=arvids.godjuks@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender) X-PHP-List-Original-Sender: arvids.godjuks@gmail.com X-Host-Fingerprint: 74.125.82.170 mail-we0-f170.google.com Received: from [74.125.82.170] ([74.125.82.170:34965] helo=mail-we0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B9/47-00152-A91B85F4 for ; Thu, 08 Mar 2012 08:18:19 -0500 Received: by werh12 with SMTP id h12so357610wer.29 for ; Thu, 08 Mar 2012 05:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=rs7yvb+BB+m+fb+ymJtDE2GZ9RU353RHGFBqmerzwUg=; b=EYGBYzarA8hs2fwBHlhIiM0RH3mR2MFoCu0UPmZFkgXdyBf5SmpPbA9+ow9u0FudP1 zhM4W33IJ0YgMDA1YrMZFVxseFZ552W/pdCe1Fxb3Ue9Whmq8qqSGeoDAZ1kfZqpNgDR uUiYafT1+PCvqFtGUBhqLY2A/LOBX5eSpM2SEcNk3Z7DMkoMTEGGxacI8d50HJJ6eH/w oWScoHbTFYJ2m5WErj1OjwMVvNdQkPJSPtlSa+SMDlvjpBR9r5e3bs8MXjmxKuPD9DT1 6oiuDt64iXaoA9We7V7hXWF2YFsFf3bMUZr61m/1GEJH2qOwhjp9iGWn5J8Q9hy21E9D PRYw== Received: by 10.180.93.4 with SMTP id cq4mr12625566wib.21.1331212696015; Thu, 08 Mar 2012 05:18:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.117.1 with HTTP; Thu, 8 Mar 2012 05:17:55 -0800 (PST) In-Reply-To: References: <52.38.15021.3A1E65F4@pb1.pair.com> <4F570EBB.6030103@sugarcrm.com> <60744d7ea642fe03c7110502a3f4276a@mohiva.com> Date: Thu, 8 Mar 2012 15:17:55 +0200 Message-ID: To: John Crenshaw Cc: "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) 2012/3/8 John Crenshaw : > From: Arvids Godjuks [mailto:arvids.godjuks@gmail.com] >> That's why I described the rules when type juggling comes into play. >> If you send a string number, it is converted from string to number by th= e type hint. If you send a string of characters and pass it to a int type h= inted function - sorry, but it's you who shout yourself with a shotgun, not= someone else. > > If you are determined to have it this way and cannot yield, then you are = off topic. This thread was built around the explicit premise that any scala= r type hint MUST be more forgiving than that, and if we take that away ther= e's quite literally nothing more to talk about. Regardless of how anyone fe= els about it, the core devs will never accept what you are insisting on abo= ve. (If you want proof, look at the prior debates on this issue.) This disc= ussion has no purpose unless it can actually accomplish something meaningfu= l, so it started by accepting this as a fundamental requirement. Allowing s= trings to be implicitly converted to lower types when possible, regardless = of whether the reason offends your sense of how code should have been writt= en, is a vital compromise in the process of improving the typing in PHP. > > John Crenshaw > Priacta, Inc. Well, if your type hints gets more forgiving, than it's the same that was proposed by this function a((int) $arg) {} And in this case hints have no meaning at all - it's just other syntax to do the conversion that now looks like this function a($arg) { $arg =3D (int)$arg; } And please give an answer to this question: If we make hints forgiving (like type casting), then what we have to do with current array type hints - it gives error on anything but arrays? Change it back so it does a conversion to array? Sorry, but it will make a mess in my code, because I already use hints for arrays and objects and changing their behavior is just out of the question. I do not remember devs explicitly saying that something like I proposed will not be accepted. They said there will be no strict type hinting or strict variable typing. And they do not want to add another syntax for type juggling functionality. So, if only i'm not mistaken, my idea is somewhere in between and doesn't look weird or extraordinary. It just adds ability to make arguments of the function/method be more picky about what they can receive. Maybe i'm mistaken, but I have a distinct impression that many of the posters will use type hints all over the place if and when they will be added and base their ideas on that. Don't get me wrong, but the auto-casting type hints are really needed only when you really write all the code with type hints in every function/method you define and you don't want to do manual conversions all the time. Maybe this is that case when people tend to get min-max and do not consider the average use? My average use of currently available type hints is low in WEB environment and only in internal stuff where user input doesn't make in unchecked. And I had quite a good use of them in a console daemon where there is no user input at all (only working with database). As to breaking some BC when making keywords such as "string", "int", "float" - that's what the major releases are for. When you introduce ANY keyword there is a possibility that someone is using it and it will break his application. It's a risk, yes. But now days refactoring instruments are very good and changing class name thought out the project is no big deal really - just make sure people are informed.