> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Saturday, February 21, 2015 8:12 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Zeev, > > First off, thanks for putting forward a proposal. I look forward to a > patch > that can be experimented with. > > There are a few concerns that I have about the proposal however: > > > Proponents of Strict STH cite numerous advantages, primarily around code > safety/security. In their view, the conversion rules proposed by Dynamic > STH > can easily allow ‘garbage’ input to be silently converted into arguments > that > the callee will accept – but that may, in many cases, hide > difficult-to-find > bugs or otherwise result in unexpected behavior. > > I think that's partially mis-stating the concern.
I don't think it is, based It's less about "garbage input" > and more about unpredictable behavior. You can't look at code and know > that it will not produce an error with dynamic typing. That's one of the > big > advantages of strict typing that many people want. In reality the reasons > are > complex, varied and important to each person. > > > 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. > > 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. > > 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. > > In reality, the only thing PHP's type system is consistent at is being > inconsistent. > > > > In the "Changes To Internal Functions" section, I think all three types > are > significantly flawed: > > 1. "Just Do It" - This is problematic because a very large chunk of code > that > worked in 5.x will all of a sudden not work in 7.0. This will likely > create a > python 2/3 issue, as it would require a LOT of code to be changed to make > it > compatible. > > 2. "Emit E_DEPRECATED" - This is problematic because raising errors (even > if > suppressed) is not cheap. And the potential for raising one for a > non-trivial > percentage of every native function call has the potential to have a > MASSIVE > performance impact for code designed for 5.x. Without a patch to test, it > can't really be codified, but it would be a shame to lose the performance > gains made with 7 because we're triggering 100's, 1000's or 10000's of > errors > in a single application run... > > 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). > > > > Moving along, > > > 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. > > > For example, a “32” (string) value coming back from an integer column in > > a > database table, would not be accepted as valid input for a function > expecting > an integer. > > There's an important point to consider here. You're relying on information > outside of the program to determine program correctness. > So to say "coming back from an integer column" requires concrete > knowledge and information that you can't possibly have in the program. > What happens when some DBA changes the column type to a string type. > The data will still work for a while, but then suddenly break without > warning > when a non-integer value comes in. Because the value-information comes > from outside. > > 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. So semantic information about > the > value is places right at the point of entry (forcing the code to be more > explicit > and clear). > > Additionally, with the dual-mode proposal DB interactions can be in weak > mode and have the exact behavior you're describing here. Giving the user > the > choice, rather than making assumptions. > > > Strict zval.type based STH effectively eliminates this behavior, moving > > the > burden of worrying about type conversion to the user. > > Correct. And you say that as if it's a bad thing. Being explicit about > type > conversions isn't what you'd do in a 10 line-of-code script where you can > realize what the types are by just thinking about it. But on large scale > systems > exposing the type conversions to the user gives the power to actually > understand the codebase when you can't fit the whole thing in your head at > the same time. > > So what you cite here as a disadvantage many consider to be an advantage. > > > Performance > > I find it funny how the non-strict crowd keeps bringing up performance... > > > It is our position that there is no difference at all between strict > > and coercive typing in terms of potential future AOT/JIT development - > > none at all > > So really what you're saying is that you disagree with me publicly. A > statement which I said on the side, and I said should not impact RFC or > voting > in any way. And is in no part in my RFC at all. Yet brought up again. > > > 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. 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. > > > > In short, I think the concerns around the handling of internal functions > is > significant enough to cause major concern about this proposal. > > Thanks > > Anthony > > On Sat, Feb 21, 2015 at 12:22 PM, Zeev Suraski <z...@zend.com> wrote: > > All, > > > > > > > > I’ve been working with François and several other people from > > internals@ and the PHP community to create a single-mode Scalar Type > Hints proposal. > > > > > > > > I think it’s the RFC is a bit premature and could benefit from a bit > > more time, but given the time pressure, as well as the fact that a not > > fully compatible subset of that RFC was published and has people > > already discussing it, it made the most sense to publish it sooner > > rather than later. > > > > > > > > The RFC is available here: > > > > > > > > wiki.php.net/rfc/coercive_sth > > > > > > > > Comments welcome! > > > > > > Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
