Hi! >> -- Can the code generated for a strict type hint can somehow be optimized significantly better than the code generated for a dynamic/coercive type hint. > And me, who wrote an AOT compiler that does **exactly** this, claim
Sorry, did exactly what? Here a bit more explanation would help. > However, since test_strict() is compiled, there's no reason to > dispatch back up to PHP functions for strict_foo(). In fact, that > would be exceedingly slow. So instead, we'd compile strict_foo() as a > C function, and do a native function call to it. Never having to check > types because they are passed on the C stack. Doesn't that assume strict_foo() is always called with the right type of arguments? What exactly ensures that it does in fact happen? Shouldn't you have the type check _somewhere_ to be able to claim this happens? test_foo() doesn't do any checks, so what ensures $x is of the right type for C? And if the check is there, how is it better? > 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). I don't get the backwards part - I think you claimed it last time we discussed it but I haven't seen your answer explaining why it's OK to just ignore cases when the variable is of the wrong type. Right now, it looks like you claim that if somebody has a call strict_foo($x) and strict_foo() accepts integers, that magically makes $x integer and you can generate code everywhere (not only inside strict_foo but outside) assuming $x is integer without actually needing a check. I don't see how this can work. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
