Zeev, On Sat, Feb 21, 2015 at 5:02 PM, Zeev Suraski <z...@zend.com> wrote: >> -----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.
They are inherently different because we (PHP) say they are. Plenty of other languages out there say they are not inherently different. You want to keep them separate? That's fine. But it can be useful to model a language without making them separate. So I don't agree that they are "fundamentally" different. Is it worth going into that now? No. But I think it's a valid viewpoint. >> 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. The other RFC comes from the standpoint that there's nothing wrong with coercive. So there's no need for a roadmap. There's no need for people's code to break when they upgrade, ever. There's no need for an upgrade path because everything will just work. It introduces a new mode that users can opt into. And in practice, they should use both modes because different needs have different solutions. "with two potential 'camps' of developers forming up" Have you looked at the community lately? That's been happening for a decade. One camp likes to engineering everything out using classes and libraries. The other keeps using PHP procedurally and ignoring changing "best practices" (and I do mean the quotes). Does that make one better than the other? NO. And that's PHP's strength. It gives both sides the power to keep doing what they want to be doing without having to give up or be burdened by the other side. And that's what my RFC provides. It doesn't force behavior or belief on anyone, it gives the choice. >> 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. Sure, some people will do that. Just like people still use single quotes because they are faster. But the way you fix that is not to handicap the language (we do have eval() and goto, no?) but to educate the users. > 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. Vulnerability scanning is a subset of static analysis. One that does not rely on typing, but tainting. All it needs to do is watch variable flow with explicit "markers" to make the input safe. There are definitely other techniques involved as well. What I'm talking about is correctness provers. Static analyzers that look at an entire codebase and ensures that information flow through it is correct and will not error at runtime. Precisely what HHVM's type checker does. > Two more things regarding the competing RFC – it’s still alive, and being > promoted for PHP 7.0; And while it doesn’t create a huge BC break, it > allows developers to selectively create localized BC breaks, on a per file > basis. No, it does not. A BC break is something where existing code works, and you do nothing more than upgrade and have the new code not work anymore. With the other dual-mode RFC, if a user opts-in (enables strict mode), if code doesn't work that's not a BC break. That's a case of "you told us explicit you don't want this code to work if it's invalid, and guess what, it's invalid". Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
