Dmitry, On Wed, Feb 25, 2015 at 7:19 AM, Dmitry Stogov <dmi...@zend.com> wrote: > Hi Anthony, > > Few notes: > > - first of all, it would be great to split the voting questions: 2/3 - > implement scalar type hinting + 1/2 - in addition add strict type hinting as
I've mentioned this a few times, but I disagree with that concept. I believe RFCs should fully describe a feature and should be voted on in whole. Additionally, it presents a problem when it comes to voting. What if a person wants strict types. And it looks like it's overall going to pass, but that weak types is winning. What's the best way for them to vote? No. For the entire proposal. I'd rather keep the vote about one thing, and one thing only. > you propose. I think, the concept of run-time declare() switch is not > designed well. It just affects VM and JITed code in negative way, because in > each function we will have to handle both options > https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-3054389ad750ce9a9f5895cd6d27800fR3762 > and also set additional flag on each call > https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-3054389ad750ce9a9f5895cd6d27800fR2802 What negative way is that? It's a clearly defined switch, kept in a clearly defined place. And considering it's a purely compile time construct, I fail to see how it could possibly affect either the VM or JITed code in a negative way. Heck, if we really wanted to, we could compile a separate ZEND_DO_FCALL opcode for strict types: ZEND_DO_STRICT_FCALL, which hard-codes the strict data. > > - resource type hint may be useful in the same way as all other types The problem here is typing on a resource doesn't give you enough information to be "safe": function foo(resource $bar): string { return fread($bar); } foo(mysql_connect(...)); I think a longer-term plan to replace (transparently) resources with objects would be far more beneficial. > - it may make sense not to disable bool/int/float/string classes at all. we > may just don't allow them in type hints. This will break less applications. It'll still break applications, because you can no longer do: function foo(String $string) {} foo(new String); I think leaving the ability to create a class named "string" while at the same time removing the ability to type against it is not only weird, but definitely not something I think we should do (it's just way to inconsistent). Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
