> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Saturday, February 21, 2015 10:08 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > 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.
Objects and scalars are fundamentally different, definitely in PHP.. There's no standard way to convert an instance of a certain class to an instance of another class, at least not in PHP. There is, however, a standard way of converting different types of scalars to one another, and this behavior is extremely ubiquitous in PHP. That is the reason that when class type hints were introduced, it was at the *condition* that we'll not have strict scalar type hints, because scalars were (and still are) so fundamentally different than objects and in many cases can losslessly change type in a well-defined manner. Perhaps if we had the coercive STH idea back then we could have saved us all a lost decade without scalar type hints. I'll say it again - scalars and objects (and for that matter any non-scalar type including arrays and resources) - are inherently different, and striving for consistency between them should not be a goal IMHO. > Let's agree to disagree that an ini setting will be better than a per-file > setting. We can agree to disagree on that, but not on the fact that the Coercive STH RFC provides a roadmap, at the end of which we'd have a single mode, consistently behaving(*) and more secure-for-everyone language - and one without that INI entry (it's a temporary measure that will be removed). The Dual Mode RFC, on the other hand, we're introducing two modes that we'll have to support for all eternity, with two potential 'camps' of developers forming up, and with no security benefits for anybody who doesn't choose to flip on the strict switch. (*) With the exception of Scalar/non-Scalar consistency, which again, I find hard to accept as a valid goal. > >> > 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. Thanks. > 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. This ignores the reasonable guesstimate - raised by several people here - that many will flip Strict mode on because they'd think it makes them inherently safer, faster, or just a good thing to do. Everything I've learned about PHP in the last couple of decades tells me there are going to be plenty of those. Those are the same people who would quickly then add explicit casts to make the code work again; Those are also people who would benefit a lot more from a single mode system that would point out real problems in their code, with likely very few false positives or false negatives. > >> > 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)... Of course an opinion can be patently false, however, you were talking about what I wrote, not the opinion. Let me illustrate it. Watch youtu.be/kjvQ9eT_t-U - it's worth the one minute of your time if you haven't already seen it. Now, apparently, that guy absolutely believes in what he says. What he says is absolute nonsense, but not the fact he believes in it. Now, I took an extreme case to illustrate my point and I obviously don't aim to be compared with this guy, but hopefully that takes the nitpicking point across. Sorry, I've become a bit sensitive to the explosion of 'patently false' statements here, I find them somewhat offensive and aiming to shut discussion down. To the point itself, with all due respect, the Static Analysis gains you believe exist in Strict STH aren't even remotely at the same bucket as gravity, which has been proven with scientific method. More on that below. > > 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. Actually, that's not the scientific method I know. In the scientific method I know, a theory needs to be proven for it to be accepted as true - and not as you seem to suggest, that a theory is deemed true unless it's proven untrue. 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. First, you don't need to retract the comment as evidently it's clear you believe in it. It's fine that we hold different views. But we should both be allowed to say what we think and have this difference of opinion be widely known. Secondly, there you are: http://www.checkmarx.com/ - they've been developing pretty amazing static analyzers for PHP for years, and without any type of scalar hints - strict or weak. Last - I'm not sure how whether or not static analyzers exist for PHP proves or disproves whether the delta between Strict/Dynamic type hints helps Static Analysis in any way. You could still be right even though static analyzers already exist for PHP (they could be made better, perhaps), and you could still be wrong if there were no static analyzers for PHP in existence. > 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). My recommendation is that we again agree to disagree, as you suggested. Agreeing to disagree doesn't mean I accept your position as I accept gravity, or that I start hiding the fact I disagree (and vice versa). It means we both disagree with each other respectfully. In the RFC I intentionally didn't say that Static Analysis being helped by Strict STH is nonsense or 'patently false' - but instead, pointed out that we don't believe there are substantial gains to be had there. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
