Zeev, On Fri, Feb 13, 2015 at 1:20 PM, Zeev Suraski <z...@zend.com> wrote: >> With that said, there's nothing stopping you from putting up your time to >> create a competing proposal and patch. If you really believe that weak >> types >> are the better way forward, why not codify that? If only one of the RFCs >> passes, then you have your answer. If both pass, we can simply have >> another >> vote to choose which to move forward with. >> Competition is healthy for the community. > > That may be a good idea. > >> You also said earlier in the thread that you don't agree with the points >> that I >> made on my blog post (http://blog.ircmaxell.com/2015/02/scalar-types-and- >> php.html). Can you share what you don't agree with (in the comments or >> this >> thread)? >> Rasmus posted some issues, most of which I consider details in this >> proposal >> (declare() and lack of handling the int->float conversion >> case) and I replied to them (I think they are handleable). If you have >> other >> disagreement, why not share? > > I've shared them countless times over the past decade.
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. > 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. > native syntax. That's bound to make a lot more developers care about the > internal type of scalars, and rely a lot less on PHP's dynamic typing - or, > in other words, make PHP a more complex language. While Andrea's RFC does a > significantly better job at hiding strict typing from uninterested parties, > ultimately, mostly everyone will bump into it and have to accustom > themselves to a typing behavior that's never ever existed in PHP. Two > examples that come to mind are people working on shared code (not exactly an > uncommon occurrence) and variables that find their way into internal > strictly-typed calls, which would result in obscure messages for someone > that's used to "32" and 32 to be virtually identical in PHP. 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. There's a reason we don't see many static analyzers for PHP. I wrote one, and I can tell you that it only works by eliminating mixed types (if it's mixed, it gives up). You can't do it for mixed types in PHP simply because the analysis depends on values not present in the code at compile time. Yet static analyzers are incredibly useful for finding bugs. And making it easier to work on shared code since they know if they make a breaking change, they'll be told about it. That's why the VAST majority of large codebases (> 1 million lines of code) are written using typed languages (and many of those not are moving in that direction). Because the benefits of typing on large scale teams isn't something of debate anymore. >> I would especially would like a response to the point that I made where I >> showed 3 examples where weak hints of any type would cause subtle and >> hard-to-find bugs; one of which was a high-level security risk. > > Languages have advantages and disadvantages. PHP's biggest advantages is > developer productivity, and dynamic typing is a big component of that. Does > it have disadvantages? Sure. But PHP was designed with the belief that the > advantages of dynamic typing outweighs that of strict typing. In the few > cases where strict type checking is needed, you have the facilities to do > that in a bit of custom code. That balance of making strict type checks > possible - but not at the level of native constructs - is the right balance > for a dynamically typed language like PHP. You'd only add strict type > checking if it's really needed, and not as an afterthought. 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? > 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. https://github.com/search?p=4&q=%22curl_setopt%28%24ch%2C+CURLOPT_SSL_VERIFYHOST%2C+true%29%3B%22&ref=searchresults&type=Code&utf8=%E2%9C%93 This is only caught by new versions of CURL which removed option 1: https://github.com/php/php-src/blob/master/ext/curl/tests/bug63363.phpt 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. > >> One final side-point: In my work on Recki-CT, I learned very early on that >> casts are quite expensive. When compiling mandel() from Zend/bench.php, >> the implicit casts that were happening on $w2, $x and a few other vars >> (which were ints) to floats for the computation added approximately 10% to >> the runtime of the function. The casts in mandel2 accounted for 20% of the >> runtime. Let me say that again: the >> int->float conversion in the loops accounted for between 10% and 20% >> of the function call. And that's not a dynamic cast (a branch based on >> type), >> it's a single `fild` instruction. Having the ability to statically know >> that a cast >> will never be needed can result in significantly faster (and easier) >> native code >> generation... > > Two points on this one: > 1. PHP's motto has always been developer productivity over performance, if > squeezing performance meant bothering the developer with implementation > details he shouldn't care about. We prefer to work hard on getting the > engine optimized, and let the developer focus on creating the business logic > in the simplest possible way. By the way, in this particular case, it's > possible to automatically detect that the variables in question are all > floats, and have the engine automatically do it for you. It's not easy, but > can be done. If we ever have JIT in PHP, it will do that automatically for > developers - which is exactly PHP's spirit. > 2. More importantly to our discussion, there's zero practical difference in > terms of performance implications between weak and strict typing. Inside > the function code, you can rely in exactly the same way - with absolute > confidence that you got what you asked for. In the calling code - you can't > assume anything about the value being passed and must conduct checks into > it - unless it too came from a type-hinted argument and you actually tracked > that it's not being touched anywhere in the function code (which may result > in its type being altered). Then too - it doesn't matter if it came from a > weak type hint or a strict one. The result is identical if your function > was reached. The only difference is that in weak types there'll be > auto-conversion if needed - but unlike the pure-variable-juggling code in > mandel(), in such a case - the conversion will be negligible compared to the > function call overhead, and potentially even the extra type checking code > you'd add. > > Everyone forming their opinion regarding weak vs. strict vs. both should > know there's no performance impact to be expected from any choice we make. 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. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
