Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83300 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 95659 invoked from network); 20 Feb 2015 14:08:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Feb 2015 14:08:25 -0000 Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.216.174 mail-qc0-f174.google.com Received: from [209.85.216.174] ([209.85.216.174:33519] helo=mail-qc0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5A/56-54878-8DF37E45 for ; Fri, 20 Feb 2015 09:08:25 -0500 Received: by qcxm20 with SMTP id m20so754120qcx.0 for ; Fri, 20 Feb 2015 06:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=31WzcarT8/34CfdoGFD7HQ1k6XM6NJJVfFPSoohy54o=; b=CJm+dh24ofcg4FfcPPSc7q5SPwLKbRNkuctuJ+XOA1to/pwDqXX2Xv9j3qyJ2ZSsE+ +5Zsu3RwACek1R+9ogjdrG6ZkdbHQ3CFPkqulKuHHEsfwtmoHa/f4QAOiJLj+guYNBpe LCqdKKqaYaPSxlutYUFG4lB0eRSoNTzmdjj5xmUvR7LwQKhvW1uiQWB3gNJx3XjhbiQ7 3dNG3/3qFo1B719ClqEmF4jNhuNXBrjAbWAYgp3lIUFi78Xn02HBg2hVU9qzAl5xI8kc EubKzJcURRDFAp1LpJ+wqteHCmJxpvgxLSeENMeL3RehR+Klmikh+3xV48bxzFAJA2tN Qd8A== MIME-Version: 1.0 X-Received: by 10.140.85.137 with SMTP id n9mr22911263qgd.17.1424441301890; Fri, 20 Feb 2015 06:08:21 -0800 (PST) Received: by 10.96.39.195 with HTTP; Fri, 20 Feb 2015 06:08:21 -0800 (PST) In-Reply-To: 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> Date: Fri, 20 Feb 2015 06:08:21 -0800 Message-ID: To: Dmitry Stogov Cc: Anthony Ferrara , Larry Garfield , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Reviving scalar type hints From: pierre.php@gmail.com (Pierre Joye) hi Dmitry, On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov wrote: > On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara > wrote: > >> Larry, >> >> > 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.) >> >> For the normal compiler & engine there will be no benefit for the >> foreseeable future. >> >> For a tracing JIT compiler, there will be no advantage. >> >> 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). >> >> 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. > > > AOT compiler that know type of passed argument and expected parameter type, > may eliminate guard check independently on hint semantic (strong or week). > If you don't know first or second you'll have to generate guard code anyway > independently from hint semantic (strong or week). Is this wrong? > > We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. I think we can agree on that, and we did as far as I can tell :) > >> 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). >> > > Completely agree, changing language for compiler is not fair. > It's clear that statically typed languages are more suitable but we won't > make PHP statically typed. > Also, modern JS engines showed - what they may do without typing. Let put things correctly please: > In my opinion strict type hints may be useful for program verification, but > again, I wouldn't like to change the whole language semantic We are talking about arguments handling here. Not the whole language semantic. The way the language works will stay the same. I am not writing that for you but for all other who may be misinterpret your reply. > just to get few unit tests out of the box. Strict types handling for arguments goes way beyond having a few units tests. It would very good if one single point of the argumentation is used to generalize a cons argument. That makes no sense and it simply goes down a way I would really not like to see again. Cheers, -- Pierre @pierrejoye | http://www.libgd.org