Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83303
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7-m2a5REraebFVGiu4h67NgFrGHv+nMQ1aJrBdeEq8JQ@mail.gmail.com>
References: <011801d04a07$83ab1c00$8b015400$@php.net>
	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>
	<016f01d04a3a$e9183220$bb489660$@php.net>
	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>
	<d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>
	<CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>
	<022801d04ab1$4a0c47d0$de24d770$@php.net>
	<1913e09d7f52541901d8574d2080a63f@mail.gmail.com>
	<CAAyV7nFD=BQ5dBYiKzhbOKTomKmWvruTnb=R_n9mYB-Lz1P9pg@mail.gmail.com>
	<7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com>
	<CAPhkiZxpYbaPN1370_HFTVnBA=Jg-rU8DrB2P+2dmRcJfGWPtw@mail.gmail.com>
	<2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com>
	<CAPhkiZwcD3h42=9eak4uP9n2GBE=v0LVP6Ncq9Oz7L91dJ5y5w@mail.gmail.com>
	<4cc0c81c7199a452534bb8edcdb19914@mail.gmail.com>
	<54E589F6.9030002@garfieldtech.com>
	<d62afd01c97a2d00466ac88579fa861c@mail.gmail.com>
	<54E66569.8000709@garfieldtech.com>
	<CAAyV7nG79GbQt_hcAsV15Ad-7k7KjDW43HTGyegHPoswDMNzJA@mail.gmail.com>
	<CA+9eiLsNJVndxSwNY1bcCJ8C2vAE05STz6KdPNUT6tsHZbtxhw@mail.gmail.com>
	<CAEZPtU7-m2a5REraebFVGiu4h67NgFrGHv+nMQ1aJrBdeEq8JQ@mail.gmail.com>
Date: Fri, 20 Feb 2015 18:25:42 +0400
Message-ID: <CA+9eiLtBbpSF5dxfrgtCB8MPYmNbZemvyCFp6BBiCpAwxp1nRQ@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, Larry Garfield <larry@garfieldtech.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0115f048d3c1b1050f85d3a3
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: dmitry@zend.com (Dmitry Stogov)

--089e0115f048d3c1b1050f85d3a3
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> hi Dmitry,
>
> On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> > On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara <ircmaxell@gmail.com>
> > 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.
>

What is significant? Miracle ability of static analyzes for AOT?

I think we can agree on that, and we did as far as I can tell :)
>

I didn't agree with you.
Probably, I told that performance impact of run-time switch of type hinting
semantic is slightly negative and it would be great to fix it if possible.


> >
> >> 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.
>

I didn't hear any arguments for strict typing except for program
verification and static analyzes, may be I missed.
Please, tell me few use cases, may be it'll change my mind :)

Thanks. Dmitry.



> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>

--089e0115f048d3c1b1050f85d3a3--