Hi Larry > That not only alleviates the need to support multi-line blocks, it keeps the > match statement itself clearer to understand at-a-glance, and encourages the > definition of named, testable, small blocks of code (ie, functions whether > anonymous or not), which is a net win on its own.
I'm generally not a fan of this approach. I think it's unrealistic to expect users to move code into a separate function just because it takes two lines of code instead of one. People can't be forced into writing clean code and my fear here is that they will just revert back to using what is more convenient. > I'm fine with match() always being strict comparison, regardless of the type > mode. However, it should probably be made more explicit in the RFC that it is > unaffected by the type mode. That's a good point, I will add it to the RFC. > Possible addition: Make the match input optional, defaulting to "true". This has been proposed before. I do like it but I'm not sure if other people do. > I would strongly recommend removing the block statement support, as it just > muddies the water. As mentioned in my e-mail to Rowan, we'll probably never agree on this point. At the end of the day, you might be getting a feature you don't have to use. It barely adds any complexity to the language but will make other users happy. Thanks for you input! Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php