Hi! > We’re definitely not going to have consensus on introducing both options as > per this RFC. I for one think it’s the worst possible option.
I agree. Being wrong is bad, making a mistake is bad, but having split personality language and not knowing in which world you are - or even worse, having to deal with both worlds in the same code and being thrown back and forth between them by some little switch which is easy to miss - IMO is worse. I don't like strict typing in PHP because I think it is contrary to the idea of how dynamic languages should work, but I'd rather have that then two sets of rules living within the same code, especially when looking at the function I can't even know how it would work without checking if there's a declare hiding somewhere. And refactoring becomes a nightmare - what if I moved function from strict world to non-strict world or vice versa? I also agree with Dmitry in other thread - if some conv rules are so bad everybody hates them (or at least you think it is the case :), we can change them. We are already on that track with some weird ones like array->string. Even with BC effects, IMO better than too many sets of rules. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
