Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83230 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1692 invoked from network); 19 Feb 2015 17:37:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Feb 2015 17:37:10 -0000 Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender) X-PHP-List-Original-Sender: francois@php.net X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr Received: from [212.27.42.2] ([212.27.42.2:46953] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 90/66-18870-34F16E45 for ; Thu, 19 Feb 2015 12:37:09 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id 9410C4B0163; Thu, 19 Feb 2015 18:37:03 +0100 (CET) Reply-To: To: "'Patrick ALLAERT'" , "'Sara Golemon'" , "'PHP internals'" References: <036301d04ba6$1b06cff0$51146fd0$@php.net> In-Reply-To: Date: Thu, 19 Feb 2015 18:37:00 +0100 Message-ID: <049f01d04c6a$aa928dc0$ffb7a940$@php.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04A0_01D04C73.0C5918A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKz6wpj8b81mnwJq1LfxWbU4ZJyQgJsy61hAjPXCBUCZ8lg7pr4upBw Content-Language: fr X-Antivirus: avast! (VPS 150219-0, 19/02/2015), Outbound message X-Antivirus-Status: Clean Subject: RE: [PHP-DEV] Scalar Type Hints v0.4 From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=) ------=_NextPart_000_04A0_01D04C73.0C5918A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Patrick, =20 I understand but we cannot include casting rules in the scope. And, = while attractive, I think ZPP and casting cannot share the same ruleset, = at least as long as casting is defined as aimed to being as permissive = as possible. =20 Fran=C3=A7ois =20 De : Patrick ALLAERT [mailto:patrickallaert@php.net]=20 Envoy=C3=A9 : jeudi 19 f=C3=A9vrier 2015 13:46 =C3=80 : francois@php.net; Sara Golemon; PHP internals Objet : Re: [PHP-DEV] Scalar Type Hints v0.4 =20 Le Wed Feb 18 2015 at 19:10:08, Fran=C3=A7ois Laupretre = a =C3=A9crit : > De : Patrick ALLAERT [mailto:patrickallaert@php.net] > > The biggest advantage, IMHO, is that you get the exact same result = whether > you do: > > foo((int) $value); > > or: > > foo($value); > > ... whatever the mode you are in. Wrong. Parameter parsing rules are much more restrictive than casting = rules. Only 'foo((int)'orange')' would (erroneously) succeed. =20 Francois, I'm very aware of the distinction between cast mechanism and = ZPP, but I obviously haven't been clear about the fact that the = (conversion|coercion|type juggling|...) reporting configuration I = proposed would have to be used in ZPP *AND* casting mechanism (and = anywhere else where some conversion applies). =20 With: =20 $value =3D "foo"; foo((int) $value); =20 it is: "(int) $value" that would generate a warning/error depending on = the reporting, not while parsing the parameter of function foo(), which = would receive an int (0) in this precise case. =20 And this would address the cases: =20 http://example.org/foo.php?id=3D42 http://example.org/foo.php?id=3Dbar =20 foo.php: