Anthony, I started writing this long response, but instead, I want to localize the whole discussion to the one true root difference. Your position on that difference is the basis for your entire case, and my position on this argument is the base for my entire case.
There we go: > And note that this can only work with strict types since you can do the > necessary type inference and reconstruction (both forward from a function > call, and backwards before it). Please do explain how strict type hints help you do inference that you couldn't do with dynamic type hints. Ultimately, your whole argument hinges on that, but you mention it in parentheses almost as an afterthought. I claim the opposite - you cannot infer ANYTHING from Strict STH that you cannot infer from Coercive STH. Consequently, everything you've shown, down to the C-optimized version of strict_foo() can be implemented in the exact same way for very_lax_foo(). Being able to optimize away the value containers is not unique to languages with strict type hints. It's done in JavaScript JIT engines, and it was done in our JIT POC. > With lax (weak, coercive) types, the ability to do type reconstruction > drops > significantly. Because you can no longer do any backwards inference from > other function calls. Which means you can't prove if a type is stable in > most > cases (won't change). Therefore, you'll always have to allocate a ZVAL, > and > then the optimizations I showed above would stop working. Again, using the scientific method I'm familiar with, that would be a theory, and it would require proof. So far I haven't seen any proof, and I believe I pretty much proved the opposite with my example. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
