Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83369 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55947 invoked from network); 21 Feb 2015 01:14:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Feb 2015 01:14:41 -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:7005] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D4/D1-45394-EFBD7E45 for ; Fri, 20 Feb 2015 20:14:40 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id E7AE14B0175; Sat, 21 Feb 2015 02:14:31 +0100 (CET) Reply-To: To: "'Anthony Ferrara'" Cc: References: <011801d04a07$83ab1c00$8b015400$@php.net> <016f01d04a3a$e9183220$bb489660$@php.net> <022801d04ab1$4a0c47d0$de24d770$@php.net> <1913e09d7f52541901d8574d2080a63f@mail.gmail.com> <7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com> <2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com> <4cc0c81c7199a452534bb8edcdb19914@mail.gmail.com> <54E589F6.9030002@garfieldtech.com> <54E66569.8000709@garfieldtech.com> In-Reply-To: Date: Sat, 21 Feb 2015 02:14:32 +0100 Message-ID: <059701d04d73$bf9a4280$3ecec780$@php.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGD0sLDaA+/0NIeBlQhQC5OtPA/xwHih9+6AanvcsEBj7eMCwEU0CpMAs0H7+gBDwGZjwJNu28fAX8sxVQAox2RWwKtsa6+Ap7Ai84CNkZj6gJ0jMndAd8n3MgBp3GfaALFVDbFAc1QaI+cjsur0A== Content-Language: fr X-Antivirus: avast! (VPS 150220-1, 20/02/2015), Outbound message X-Antivirus-Status: Clean Subject: RE: [PHP-DEV] Reviving scalar type hints From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=) Hi Anthony, I guess you would keep supporting __toString() ? So, you should probably = consider 'string' as 'string|object'.=20 Adding this case to 'float' meaning 'int|float' and 'callable' resolving = to 'string|array|object', are you sure it's worth the pain implementing = and supporting a dual-mode mechanism, compared to the ruleset I am = intending to propose (currently in draft): = https://wiki.php.net/rfc/zpp-conversion-rules ? Actually, using such ruleset, I guess you could infer less, but the = difference wouldn't be so important. Only 3 conversions still use value, from which one can be made = type-dependent-only if requested during discussion (float to int = proposed as lossless-only). Every type except int, float, and string are = also proposed as 100% strict. I'm not sure we can go much further with a single-mode approach, but = I'll appreciate your opinion. Of course, anyone else is welcome too. Regards Fran=C3=A7ois > -----Message d'origine----- > De : Anthony Ferrara [mailto:ircmaxell@gmail.com] > Envoy=C3=A9 : vendredi 20 f=C3=A9vrier 2015 02:58 > =C3=80 : Larry Garfield > Cc : internals@lists.php.net > Objet : Re: [PHP-DEV] Reviving scalar type hints >=20 > Larry, >=20 > > Anthony, can you expand here at all about the practical benefits of > > strong-typing for variable passing for the compiler? That seems to = be the > > main point of contention: Whether or not there are real, practical = benefits > > to be had in the compiler of knowing that a call will be in "strict = mode". > > (If there are, then the split-mode makes sense If there are not, = then > > there's little benefit to it.) >=20 > For the normal compiler & engine there will be no benefit for the > foreseeable future. >=20 > For a tracing JIT compiler, there will be no advantage. >=20 > For a local JIT compiler, there can be some optimizations around > reduced conversion logic generated (and hence potentially better cache > efficiency, etc). A guard would still be generated, but that's a > single branch rather than the full cast logic. This would likely be a > small gain (likely less than 1%, possibly significantly less). >=20 > For a AOT compiler (optimizing compiler), more optimizations and > therefore gains can be had. The big difference here is that type > assertions can be done at compile time. So that means one less branch > (no guard) per argument per function call. In addition, native calls > can be used in a lot of cases, which means the compiled code doesn't > even need to know about a zval (significant memory and access > reduction). This has potential to be significant. Not to mention the > other optimizations that are possible. >=20 > However, I think making this decision based on performance is the > incorrect way of doing it. For the Zend engine, there will be no > discernible difference between the proposals. It's a red herring. The > difference I would focus on is the ability to statically analyze the > code (with the benefits that comes with). >=20 > Anthony >=20 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php