> De : Anthony Ferrara [mailto:ircmax...@gmail.com] > > 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.
Agreed. IMO, splitting votes is theoretically possible, but not in parallel. Actually, if we had wanted to proceed this way, we should already have finished the first vote. Too late now. I don't know if it was already suggested but, whatever the date each STH vote starts, I suggest we synchronize end dates, in an attempt to limit side effects. I don't know it the tool we use can be configured to allow for each user to see only his own vote before vote ends, and only global result when it is over, but it would probably improve the process a lot. Regards François > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
