> 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. Strict typing exposes data that should not be interesting in the vast majority of cases and makes it prominently available for handling using 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. > 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. 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. > 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. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
