Dmitry,
On Wed, Feb 25, 2015 at 10:13 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > > On Wed, Feb 25, 2015 at 6:03 PM, Anthony Ferrara <ircmax...@gmail.com> > wrote: >> >> 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. > > > 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 :) Yes. Because you, Zeev and Francois are making a competing proposal. Which is the better way to decide, since then people can vote independently for a specific implementation, not a complex set of switches. So if both fail, then we don't see scalar type declarations. If one passes, we know what people want. If both pass, then we deal with that then. I even agreed to postpone the vote on this proposal so you could finish yours. So please stop trying to spread FUD here and play both sides of the game. >> > 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. The call is compiled at compile time. The call's strict mode is decided at compile time. So while the actual type checks happen at runtime, and the function binding happens at runtime, the actual switch happens at compile 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. You don't need to know the destination function to determine if it's going to be strict mode or not. >> 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. I said it was my opinion. I also will not put it up to vote, because the proposal is a codification of my views for the way forward. I said I'd be open to discussing anything in the proposal. But ultimately it's a single proposal, not a menu of choices. Please stop asking me to add individual votes for every little detail. The only thing that accomplishes is making it infinitely harder for people to understand what they are voting on. Right now, it's an "all or nothing" vote. Which means that it's very easy for people to understand what they will get if it passes. >> >> "Break" is a loaded term. > > > OK. it's a BC break. > What is the reason for __toString() if it's not going to be called. It's absolutely not a BC break by any definition of the term that we've **ever** used here, nor in the community. It's 100% acceptable with semver. Heck, even Wikipedia's definition is consistent: http://en.wikipedia.org/wiki/Backward_compatibility You have to specifically opt-in to strict mode. Meaning that unless we make changes to the coercive mode, there is by definition no BC break. I expect you'll vote against the proposal either way, which is fine. But please stop spreading misinformation and using loaded terms improperly. As far as "what is the reason for __toString if it's not going to be called" I explained it right below where you quoted: > It's intentionally not calling __toString, because that's not only a > cast (like "5" -> int(5)), but it's a lossy cast (like 5.5 -> int(5) > or "5 apples" => int(5)). __toString will still work in weak mode for parameters, and you can still echo out the string just fine. But if you accept an object that implements __toString, you can't just pass it to strlen without explicitly converting it to a string first. Just like numbers. Just like all of the other conversions. Just like you can't pass a Foo instance to something expecting a Bar instance without an adapter in between. It'd be quite weird to reject int(5) for string, while accepting new FooHasToString();. So either we go full strict (hence the strict mode) or we don't (hence the weak mode). Here, we're giving the author the choice. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
