Hi Anthony, I guess you would keep supporting __toString() ? So, you should probably consider 'string' as 'string|object'. Adding this case to 'float' meaning 'int|float' and 'callable' resolving to 'string|array|object', are you sure it's worth the pain implementing and supporting a dual-mode mechanism, compared to the ruleset I am intending to propose (currently in draft): https://wiki.php.net/rfc/zpp-conversion-rules ?
Actually, using such ruleset, I guess you could infer less, but the difference wouldn't be so important. Only 3 conversions still use value, from which one can be made type-dependent-only if requested during discussion (float to int proposed as lossless-only). Every type except int, float, and string are also proposed as 100% strict. I'm not sure we can go much further with a single-mode approach, but I'll appreciate your opinion. Of course, anyone else is welcome too. Regards François > -----Message d'origine----- > De : Anthony Ferrara [mailto:ircmax...@gmail.com] > Envoyé : vendredi 20 février 2015 02:58 > À : Larry Garfield > Cc : internals@lists.php.net > Objet : Re: [PHP-DEV] Reviving scalar type hints > > Larry, > > > Anthony, can you expand here at all about the practical benefits of > > strong-typing for variable passing for the compiler? That seems to be the > > main point of contention: Whether or not there are real, practical benefits > > to be had in the compiler of knowing that a call will be in "strict mode". > > (If there are, then the split-mode makes sense If there are not, then > > there's little benefit to it.) > > For the normal compiler & engine there will be no benefit for the > foreseeable future. > > For a tracing JIT compiler, there will be no advantage. > > For a local JIT compiler, there can be some optimizations around > reduced conversion logic generated (and hence potentially better cache > efficiency, etc). A guard would still be generated, but that's a > single branch rather than the full cast logic. This would likely be a > small gain (likely less than 1%, possibly significantly less). > > For a AOT compiler (optimizing compiler), more optimizations and > therefore gains can be had. The big difference here is that type > assertions can be done at compile time. So that means one less branch > (no guard) per argument per function call. In addition, native calls > can be used in a lot of cases, which means the compiled code doesn't > even need to know about a zval (significant memory and access > reduction). This has potential to be significant. Not to mention the > other optimizations that are possible. > > However, I think making this decision based on performance is the > incorrect way of doing it. For the Zend engine, there will be no > discernible difference between the proposals. It's a red herring. The > difference I would focus on is the ability to statically analyze the > code (with the benefits that comes with). > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
