Hi Pierre, On Mon, Mar 16, 2015 at 12:31 PM, Pierre Joye <pierre....@gmail.com> wrote:
> > I'm not saying the proposed patch has bugs, but I'm saying it hides > "users' code bugs". > > > > Hiding hard to find bugs does not make much sense while there is the > proposal that finds it. > > What I'm trying to say is "Why don't we collaborate?". Let users fix > bugs at first, then > > introduce more strict type checks if it's needed. Coercive type and > strict type can co-exist > > together well, but weak type and strict type cannot. > > This example is out of the scope of this rfc. As I said many times, you > want to make php more friendly and let users write better code, that's a > good thing. However changing by default how php behaves for decades is a no > go for me. It will create more issues than it solves. > Whether we like or not, languages that support type safety are getting popularity even for web app development in these days. What Zeev is proposing is common conversion rules that many languages support already. If we are going to support type safety in some forms, we should try to adopt well established rules if it is available. I'm not objecting ZVAL type check only strict typing, but I'm suggesting Zeev's proposal is more suitable for weakly typed PHP. It works well with strict type also. Introducing type safety is the objective of scalar type hints. In other words, let users enjoy less bug programs by systematic support. IMO. What we should think is "do it right or not". Hiding type related bugs by enforcing C language like type is not good at all. IMHO. I'm 100% sure that users will have bad codes with this RFC from my code auditing experience. In contrast, Zeev's proposal will prevent "bad codes" nicely and effectively. That's the reason why I prefer the proposal. PHP is made to be a nice an easy web app language. It's clear to me which one is preferred choice for introducing type hints for "now". I understand concern about old code compatibility. If currently proposed migration term is not enough, we may extend it by other RFC. There is enough time until we introduce destructive change. We may change migration period at any time with users feedback. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
