Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83510
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGS6TE+JKV8u_P7HXfPi4yYGVh1s_XzSyE+Kbkhv06F-A@mail.gmail.com>
References: <CAAyV7nGS6TE+JKV8u_P7HXfPi4yYGVh1s_XzSyE+Kbkhv06F-A@mail.gmail.com>
Date: Sun, 22 Feb 2015 15:56:18 -0800
Message-ID: <CAEZPtU6kjP2t8keJ54R7WRRW9Kck=myJw2s4sK7-fXHi1DsS3w@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1689031de42050fb60896
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: pierre.php@gmail.com (Pierre Joye)

--001a11c1689031de42050fb60896
Content-Type: text/plain; charset=UTF-8

Can you all of you stop this madness with moving discussions off list?

It is detestable, against almost all openness and principles behind an oss
project like php. If we can't discuss anymore design, plans, ideas etc on
the list then we are doomed, for good.
On Feb 22, 2015 3:49 PM, "Anthony Ferrara" <ircmaxell@gmail.com> wrote:

> Adding in a thread that was started in private, but absolutely is
> worth sharing with the group:
>
>
> ---------- Forwarded message ----------
> From: Etienne Kneuss <colder@php.net>
> Date: Sun, Feb 22, 2015 at 8:42 AM
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
> To: Zeev Suraski <zeev@zend.com>
> Cc: Anthony Ferrara <ircmaxell@gmail.com>, Dmitry Stogov <dmitry@zend.com>
>
>
>
>
> On Sun Feb 22 2015 at 14:23:58 Zeev Suraski <zeev@zend.com> wrote:
> >
> > > There have been several attempts:
> > > for JS: http://users-cs.au.dk/simonhj/tajs2009.pdf
> > > or similar techniques applied to PHP, quite outdated though:
> > > https://github.com/colder/phantm
> >
> > Looks like WebKit's type inference is doing some pretty good job at
> > analyzing code, although I'm not sure how much of it is static vs.
> dynamic.
> > My guess is that a lot of it is static:
> > twitter.com/kangax/status/558974257724940288
>
>
> My guess would be that it's almost entirely dynamic, or probabilistic
> (e.g. this nice recent work done at ETH: http://www.jsnice.org/).
>
> I think you underestimate the difficulty of statically recovering
> precise types from no-annotations without runtime witnesses ;) You
> don't want webkit anlysing the JS for 10 minutes until it renders the
> page. It is much more profitable to JIT these.
>
> >
> >
> >
> > > You are right that the lack of static information about types is (one
> of
> > > the) a main issue. Recovering the types has typically a huge
> performance
> > > cost, or is unreliable
> >
> > We're not really talking about performance issue here, as static
> analysis is
> > a separate activity that is unrelated to runtime performance.
>
>
> What I meant was: it is a performance issue for the static analyzer,
> not PHP itself.
>
> >
> >
> > > But seriously, time is getting wasted on this argument; it's actually a
> > > no-brainer: more static information helps tools that rely on static
> > > information. Yes. Absolutely. 100%.
> >
> > There's still disagreement between us on whether the different behavior
> of
> > Strict STH constitutes additional static information or not, as it
> doesn't
> > give you any extra information on the value being fed to the function,
> and
> > it doesn't give you any extra information on what the function will
> receive.
> > It only gives you information about how the function would behave if it
> gets
> > a wrongly-typed value.
>
>
>
> 1) for forward analyses (which are the most common for these
> applications): it gives you precious information from the beginning of
> the function and forward. You can consider it similarly to a cast: You
> don't necessarily know what the value coming in is, but you know which
> type you are having from that point forward.
>
> 2) backward analyses could piggy-back the type constraints from the
> functions (strict or no strict) and check that they are met when
> constructing the value fed to the function.
>
> Having worked several years on static analysis tools for languages
> such as PHP, I can guarantee you that this information would help a
> lot. However, the other dynamic feature of PHP would still make
> analyses slow/unreliable/imprecise. Let's not imagine that this is the
> only thing missing for PHP to be static-analysis-wonderland, far from
> it.
>
> >
> > But my the bottom line is exactly the bottom line you ended with, and
> what I
> > answered you on-list - how much weight should Static Analysis
> improvements
> > have on our decision to introduce new language features?  My answer is
> not
> > that much, if they have downsides.  Static Analyzers should be designed
> for
> > languages and not vice versa.
>
>
> I fully agree in general that the flow should be this way. But it
> remains a bonus if a certain feature, as a plus, would help external
> tools. I believe it is worth mentionning..
>
> >
> > Thanks,
> >
> > Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c1689031de42050fb60896--