Re: Re: [RFC-Discuss] Scalar Type Declarations v0.5

On Wed, Feb 25, 2015 at 6:03 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote: > Dmitry, > > On Wed, Feb 25, 2015 at 7:19 AM, Dmitry Stogov <dmitry@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. > It's also a reason why others may vote against the whole and we will get nothing. > > I'd rather keep the vote about one thing, and one thing only. > I got you. All or nothing :) > > > 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. > I post the links to the important changes above. Even JITed code will have to implement these additional checks in run-time. > 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. > It's not so simple, because you don't know the function at compile-time. > > > > > - 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. > Not all resources may be replaced with objects. > > - 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); > right. but this is a smaller break. > 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). > this is your opinion. I have another. I don't know opinion of others. Why not to 50/50 voting. If you don't do it, may be I should do. Thanks. Dmitry. > > Anthony >