On Sat Feb 21 2015 at 21:08:39 Anthony Ferrara <ircmax...@gmail.com> wrote:
> Zeev, > > I won't nit-pick every point, but there are a few I think need to be > clarified. > > >> > Proponents of Dynamic STH bring up consistency with the rest of the > >> language, including some fundamental type-juggling aspects that have > been > >> key tenets of PHP since its inception. Strict STH, in their view, is > >> inconsistent > >> with these tenets. > >> > >> Dynamic STH is apparently consistency with the rest of the language's > >> treatment of scalar types. It's inconsistent with the rest of the > >> languages > >> treatment of parameters. > > > > Not in the way Andrea proposed it, IIRC. She opted to go for consistency > > with internal functions. Either way, at the risk of being shot for > talking > > about spiritual things, Dynamic STH is consistent with the dynamic > spirit of > > PHP, even if there are some discrepancies between its rule-set and the > > implicit typing rules that govern expressions. Note that in this RFC I'm > > actually suggesting a possible way forward that will align *all* aspects > of > > PHP, including implicit casting - and have them all governed by a single > set > > of rules. > > The point I was making up to there is that we currently have 2 type > systems: user-land object and ZPP-scalar. So in any given function you > have 2 type systems interacting. The current ZPP scalar type is > dynamic, and user-land object static. > > With the proposal here, you'd unify user-land scalar to behave as > zpp-scalar. So you'd have two type systems in any given function: > scalar and object (which behave differently). > > My proposal gives you the same two by default (scalar and object) and > a strict switch to collapse them into a single, unified type system. > > This is even more apparent with the int-float acceptance, because we > can mentally model Float as an object that extends Int. Then it makes > perfect sense why you'd accept ints where you see floats, but not the > opposite. > > >> However there's an important point to make here: a lot of best practice > >> has > >> been pushing against the way PHP treats scalar types in certain cases. > >> Specifically around == vs === and using strict comparison mode in > >> in_array, > >> etc. > > > > I think you're correct on comparisons, but not so much on the rest. > Dynamic > > use of scalars in expressions is still exceptionally common in PHP code. > > Even with comparisons, == is still very common - and you'd use == vs. === > > depending on what you need. > > > >> So while it appears consistent with the rest of PHP, it only does so if > >> you > >> ignore a large part of both the language and the way it's commonly used. > > > > Let's agree to disagree. That's one thing we can always agree on! :) > > I'm talking about the object system. I don't think you're disagreeing > that it's static. Hence coercive scalars are consistent only if you > look at 1/2 the type system. That was the point I was making there. > > >> 3. "Just Do It but give users an option to not" - This has the problems > >> that > >> E_DEPRECATED has, but it also gets us back to having fundamental code > >> behavior controlled by an INI setting, which for a very long time this > >> community has generally seen as a bad thing (especially for portability > >> and > >> code re-use). > > > > I do too, and I was upfront about their cons, not just pros. And yet, > they > > all bring us to a much better outcome within a relatively short period of > > time (in the lifetime of a language) than the Dual Mode will. > > Let's agree to disagree that an ini setting will be better than a > per-file setting. > > In fact, I personally think this is major enough of an issue that I > will vote no simply on this reason alone (type behavior depending on > an ini setting in any way shape or form). > > >> > Further, the two sets can cause the same functions to behave > >> > differently depending on where they're being called > >> > >> I think that's misleading. The functions will always behave the same. > >> The difference is how you get data into the function. The behavior > >> difference > >> is in your code, not the end function. > > > > I'll be happy to get a suggestion from you on how to reword that. > > Ultimately, from the layman user's point of view, she'd be calling foo() > > from one place and have it accept her arguments, and foo() from another > > place and have it reject the very same arguments. > > Let me think on it and I will come up with something. > > >> With strict mode, you'd have to embed a cast (smart or explicit) to > >> convert to > >> an integer at the point the data comes in. > > > > First, I'm not aware of smart/safe casts being available or proposed at > this > > point. > > Secondly, why at the point the data comes in? That would be ideal for > > static analyzers, but it's probably a lot more common that it will be > done > > at the first point in time where it gets rejected. > > By "smart cast" I was referring to a function which checked > is_numeric(). Not a new language construct. > > > I have a hard time connecting to the 'power' approach. I think > developers > > want their code to work, with minimal effort, and be secure. Coercive > > scalar type hints will do an excellent job at that. Strict type hints > will > > be more work, are bound to a lot of trigger "Oh come on" responses, and > as a > > special bonus - proliferate the use of explicit casts. Let me top that - > > you'd have developers who think they're security conscious, because > they're > > using strict mode - with code that's full of explicit casts. > > I agree we should have users avoid explicit casts. That's why the > dual-mode proposal exists. If users don't want to control their types, > they should use the default mode. And everything works fine. > > If they know what they want, then the explicit cast becomes a > documenting piece of information that "this is supposed to happen". > Ex: > > function takesInt(int $a) {} > > function foo(float $b) { > return takesInt($b); > } > > In weak mode, that "just works". But is it supposed to just work? You > have no idea. The next developer who comes will look at it and ask "is > that supposed to truncate, or was that an oversight?" and have no > idea. But in strict mode, placing an explicit cast before $b shows the > next developer who comes there "the truncation was intentional". > > >> > Static Analysis. It is the position of several Strict STH proponents > >> > that Strict STH can help static analysis in certain cases. For the > >> > same reasons mentioned above about JIT, we don't believe that is the > >> > case > >> > >> This is patently false. > > > > It's actually patently true. We don't believe that is the case. QED. > > To understand why "we don't believe" can be false, let's make an > analogy: I can say that I don't believe in gravity. That doesn't mean > that the opinion isn't patently false just because it was stated as an > opinion (or rather the "believe" is true, but the implication of the > belief is false)... > > > > >> Keep not believing it all you want, but *static analysis* > >> requires statically looking at code. Which means you have no value > >> information. So static analysis can't possibly happen in cases where you > >> need > >> to know about value information (because it's not there). Yes, at > function > >> entry you know the types. But static analysis isn't about analyzing a > >> single > >> function (in fact, that's the least interesting case). It's more about > >> analyzing a > >> series of functions, a function call graph. And in that case strict > typing > >> (based > >> only on > >> type) does make a big difference. > > > > I think it's fair to say that while we were unable to convince you > there's > > no tangible extra value in Strict STH compared to any other kind of STH > that > > guarantees the type of value a function will get, you were also unable to > > convince Dmitry, Stas or myself - all of which independently discussed it > > with you. Again, despite that, I'm not saying that you're "patently > wrong", > > just that I don't believe you're right. > > I've built a static analyzer that's public. I've talked to people who > build them for a living. I don't claim to be an expert in them (far > from it), but what I've seen and learned is that what you're talking > about here either isn't possible (yet) or is difficult enough to be > impractical (in terms of computing resources necessary). > > You can disagree with me all you want. You don't even need to convince > me. All you need to do is disprove me. Show me a static analyzer for a > sufficiently dynamic language (Scalar PHP or full JS - not ASM.js - > would work) and I'll happy apologize and retract the comment. But so > far all I've seen are people saying it's possible even in presence of > arguments to the contrary (why it's not possible). > > 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 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 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%. The question is rather: at what weight should we take (potential/future) external tools into account when developping language features?