On Feb 20, 2015 11:08 AM, Anthony Ferrara <ircmax...@gmail.com> wrote:
>
> Zeev,
>
> On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski <z...@zend.com> wrote:
> >
> >> On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara <ircmax...@gmail.com> wrote:
> >>
> >> verification and static analysis aren't enough?
> >>
> >
> > Anthony,
> >
> > While IMHO they're not enough to warrant substantial deviation from PHP's
> > behavior, this is a subjective question that others might answer
> > differently.
> >
> > But there's also an objective issue. There's a serious question mark
> > whether the type of hint - strict, coercive of otherwise can have any sort
> > of implications on one's ability to conduct static analysis, JIT or AOT
> > (I'm bringing those up again since they're closely related in terms of what
> > you can or cannot infer).
> >
> > Now, I'll contend that even though I don't think we are, perhaps we're
> > missing something. But at the very least it should be clear to the list
> > there's serious doubt on whether there's any extra value there even if they
> > do seem static analysis critical. If there is, it's likely to be very,
> > very limited in scope.
>
> Let's simply agree to disagree here :-)
>
> >> That's not saying you should want to use statically typed for
> >> everything. And nor would I support PHP moving to pure statically
> >> typed (which is why the proposal I'm backing doesn't).
> >
> > We're on the same page here. But the kinds of static analysis benefits you
> > seem to believe we can get from strict type hints would require that -
> > strong typing, variable declarations, perhaps changes to casting rules -
> > not just around that narrow interface between callers and callees.
> > Thankfully that's not on the table.
>
> That's also not necessary in most cases. You can infer a lot about the
> types of variables just having arguments declared. In most cases, you
> can infer enough for static analysis to work. In the cases you can't,
> that's actually a valid result of the analysis because you may have
> undefined behavior. Example:
>
> function foo(string $a): int {
> return $a + 1;
> }
>
> You can't infer the type of $a+1 because the conversion of $a->numeric
> that happens is unstable from a type perspective. But PHP's type
> changes are predictable enough where the majority of sane cases are
> predictable.
>
> Both Swift and Go behave like this. Where you only *need* explicit
> declarations on the arguments, the rest can be inferred. And where it
> can't infer, it raises a type error.
>
> Anthony
OK, performance is out then. :-)
Anthony, please explain this to me next:
Assume for a moment that:
- we tighten up the default passing rules, such that "32" passed to an int
works but "32 footsteps" errors (which I thing most are on board with doing)
- we include a strict types mode as proposed, including the logical type
widening cases
- Zend Engine gets whatever static analysis tools you feel are appropriate.
In what circumstances would I as a Drupal core developer (a few hundred
thousand lines of code, need high degree of correctness, 2500 developers),
contrib developer (a few thousand lines of code, medium correctness guarantee,
3 developers), or a client consultant (a few hundred lines of custom one-off
code, 1 developer) want to enable strict mode?
Using strict typing would out more work on me. How much varies with the part of
the application. (Closer to IO, more work.) Having it in the language means I
will run into it sometime, even if not in code I originate. If potential
performance is not a factor, then what is my carrot? What day to day benefit
would I get from doing so other than pedantry?[1] "You can infer things"
doesn't make it clear what the day to day impact is for me. Concrete examples,
please.
If it would only matter to the Facebook's of the world, well, they've got HACK
already. How would this practically help Drupal, Symfony, Zend Framework,
OwnCloud, Doctrine, phpMyAdmin, etc?
[1] I'm hardly one to object to pedantry, of course, but that in itself is not
enough to push 2500 developers to use it.
