On Sat, Feb 14, 2015 at 1:20 AM, 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. > 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,
That makes my day. And I will leep this quote in mind for any future discussions about new additions. > 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. And it will still be possible with this RFC. And this RFC allows better and more efficient way for strict areas, especially for functions/methods calls. > 2. More importantly to our discussion, there's zero practical difference in > terms of performance implications between weak and strict typing. > 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. And it is not about performance, never was and should never be. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
