Hi! > The vote would be for the RFC as it is. Possible changes are things > in the RFC I was uncertain on. I might hold votes on some of them, > actually.
I'm sorry, but this makes little sense to me. There are a number of mutually contradictory options here, how you can vote for them "as it is"? Only one of them can be implemented in code. If everybody agrees that one of them should be so, then just remove the others. If there's disagreement then how people can vote "yes" having contradictory ideas in mind? One of them would be voting "yes" for the opposite of what he thought he's voting. If the specific choices do not matter, just choose one of the options - if they're so insignificant nobody would care if you end up with another. In any case, there should be a clear understanding of what is actually proposed, instead of having 5 branching points for potentially 32 different RFCs. Or, if you absolutely can't make up your mind you can offer the options for the vote. But there should be some specificity. Otherwise the vote is meaningless - it's not the vote for specific implementation but just for some vague "let's do something I don't care what it is" and I don't think such votes make sense. Please choose something and put it to a vote. If it doesn't work, we can have different try or maybe we can just see there's no consensus on this for now, but at least we'd be clear and not think we have consensus on something but not know what actually it is. > The problem is that we *can't* be consistent. Internal functions > already live in this completely different world from user land > functions. Nullability is handled differently. They use implicit If we can't make it work well, maybe we should clean it up first instead of making it worse. > If we're just talking about casting, then this proposal does not > alter casting behaviour, in fact I've been very careful not to touch > it. It does, however, only accept a subset of the values zpp usually Casting while passing parameters is part of the casting behavior. > does. This is because it is a compromise between strict and weak > parameter typing. While I understand you might like it to be fully Again, my opinion is that bad compromise is worse than not having any implementation, because it closes future possibilities for better solution. Of course, there's a risk better one would never come, so everyone has to decide if they want "at least something" now or have a better one latter. > weak like zpp, many userland developers are in favour of something > stricter, thus the compromise. Unlike zpp's rules, at least these > rules are clearly specified and prevent data loss. I'm not sure why is this attention to data loss. In most scenarios when we're not talking about banking applications etc. if you expect a number and you've got a string "123abc", treating it as 123 is fine. No *useful* data is lost, since "abc" part passed to a numeric function is not useful data, it's garbage. Of course, for some app if you have garbage in data you're supposed to stop the app and wait for the human to arrive and clean up because it's too sensitive to trust a computer to figure it out. But in more common case just ignoring the garbage would work fine. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
