> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, February 13, 2015 9:34 PM > To: Zeev Suraski > Cc: PHP Internals > Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints > > Zeev, > > You said you disagreed with my post (meaning claims I made). I didn't ask > why you didn't like strict typing, I asked specifically why you disagreed > with > the post.
Your post supports adding strict typing to PHP, and I don't, hence, I disagree with your post. > > Strict typing exposes data that should not be interesting in the vast > > majority of cases and makes it prominently available for handling > > using > > It's data you don't think is interesting. Obviously 68% of voters right > now > think it's interesting enough to support it. There's nothing obvious about it and it's almost definitely not true either. Given the way the vote went, we have no way of knowing how many people support this because they want any type of scalar type hinting, and how many support it because they truly buy into the need to have strict typing. Had we first voted on the concept of scalar type hints, and then had an option to choose between the versions - and strict was chosen - you'd be able to make that statement. That's not what happened - and we have no way of knowing how many of the voters are just getting what they need with weak typing, and are willing to live with the extra strict typing that's added to it. > The problem is not "32" and 32. The problem is "apple" and 32. A value may > work, but we're not talking about values, we're talking about types. And > yes, > in some spots and in a lot of cases having values auto-convert is amazing. > And is one of the greatest powers of PHP as a language. But in many cases > it > leads to subtle bugs. In many cases it leads to code that's REALLY hard to > reason about ahead of time. I'll paraphrase and say that the problem isn't "apple" and 32, it's "32" and 32. The latter is a heck of a lot more common than the former, and the current RFC is going to make it a much bigger hassle to handle that data. We're focusing on the edge cases and ignoring the big, working picture. But let's focus on that "apple" and 32 edge case for a moment. I've said many times, as did others, that there are ways to solve this. The PHP way of solving it would be emitting a non-fatal warning, that those that care about could act on. Heck, maybe we can even argue for a fatal error in certain 'idiotic conversion' cases. If you remember, I was in favor of revisiting the current casting rules and tweak them to perhaps be a bit less flexible and forgiving. An extremely non-PHP way of doing it, though, would be checking the zval.type field, and rejecting "32" because it's not 32. That's exactly what you get with strict types, and that's exactly why I continue to maintain this is an alien concept to PHP. > Which is why many of us want it in PHP. So we can switch back and forth, > having the parts of the application that make sense to be fully typed, > fully > typed and the parts that don't, well, not. > > In fact, this proposal, including the strict component, embraces PHP's > dynamic nature. It simply extends what existing in 5.0 for classes to the > rest > of the type system. But it gives the developer the choice. It gives the > developer the power. > > Is that, after all, what PHP is all about? Empowering people? It's about empowering people with what we think is the right way of doing things. Everything and the kitchen sink, and let the user figure out what he wants to do - has never been our approach (even if it didn't always look that way). With that approach, why not import the whole of JavaScript into PHP? And Ruby? There's obviously some awesome stuff in there. We can import their syntax verbatim. Why not empower the developer to choose? > > To your examples, I'm not at all advocating the use of an arm's race > > to put typing information - weak or strict - everywhere. Of course, > > if you place a weak type hint in a situation where type conversion > > would pose a high security weak, it's a mistake. Keep the handling in > > custom code in such cases. In most scenarios, however, that's not the > > case. And in even more scenarios - there's no need for any kind of > > scalar > type hinting at all. > > I just want to point out that this code already exists today. Meaning that > the > code you said shouldn't exist has been live for years. I'm not sure what you mean by 'shouldn't exist', but I certainly didn't suggest it doesn't exist. This is earth, and there's buggy code everywhere. It's not exactly shocking that there are bugs around type checking out there. > So I get where you're saying "keep the handling in custom code", except > that's not what happens. Not even in our own code base. Yet alone in > other's. And it will magically happen now that type hints are available? It will make it more prominent, that's true, and it may help reduce the likelihood of bugs like the one you pointed out - but ultimately, as always, it'll be up to the human factor. On the flip side, this extra potential benefit will come at a great cost. This 'arms race' of having scalar types added everywhere across the app (as you and others seem to refer to as the true way of realizing the potential of scalar type hinting), and the obvious increase in explicit casting - is going to make PHP something very different from what it is today. And not in a good way. > That wasn't the intent of that side-note. I wasn't trying to say that > strict is > faster. I was simply trying to share a point that when you care about > generating native code (as I do), then there *are* differences between > weak-scalar and strong-scalar. I believe it was you (could have been > someone else) who said that to a JIT/AOT compiler it didn't matter. And I > was just trying to point out that's not really true. I don't think I ever said JIT doesn't matter. As you know, we've researched that heavily but never managed to come up with something that resulted in real world gains (although we made Mandelbrot go to hyperspace). PHP 7 is an indirect outcome of that effort, and we'll almost definitely want to revisit JIT in the future. Again, I'm not sure how that point you're making relates to the discussion. Fact is there's zero difference between weak and strong type hinting in terms of your ability to generate better native code. Of course, if PHP was C and you had to declare every variable and its type - it would make it immensely easier to generate efficient native code. For now, thankfully, that's not the case :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
